

Test a JPG for Progressive Rendering - dedalus
http://www.patrickmeenan.com/progressive/index.html

======
smackfu
This is neat, but it sure could use heck of a lot better index page.

Here's an example of the output:
[http://www.patrickmeenan.com/progressive/view.php?img=http%3...](http://www.patrickmeenan.com/progressive/view.php?img=http%3A%2F%2Fimg.ffffound.com%2Fstatic-
data%2Fassets%2F6%2F093a60c633f619af1ab6c8fda8635bf1fa733bb6_m.jpg)

~~~
Alupis
Can someone explain to a non-graphics person what this means?

Seems like it's just demonstrating how the JPG get's displayed on your page
while it's still being downloaded?

~~~
danbruc
The page just demonstrates that using progressive JPEGs yields a way better
user experience than sequential ones. The page essentially turns an image into
an animation simulating the loading behavior of both variants next to each
other; while the progressive image is almost immediately completely visible
(at low resolution) the sequential one builds up slowly from top to bottom.

~~~
thaumasiotes
Who says it's a better experience? I always think of progressive images as
wasting resources by transmitting worthless information (the unintelligibile
progressive image) along with the image I want to see. Text in a progressive
jpeg tends to be a smear until you have the whole thing anyway.

~~~
danbruc
I am not completely sure without checking the specification but still pretty
confident that progressive JPEGs are not made up of several images at
different resolution but just have the low frequency component first. And
images with text are neither the common use case for images nor the intended
use case for progressive JPEGs.

~~~
thaumasiotes
The user experience is not determined by how the technology secretly works.
Appearing to do something wrong is a bad thing in and of itself.

~~~
danbruc
I don't get it. Progressive JPEGs have no redundant information - I verified
that - and are usually a bit smaller than sequential ones because of a more
favorable arrangement of different components for entropy coding. And
producing initially blurry images of text is not the fault of progressive
JPEGs but at most a bad technology choice for a given use case. The image will
get fully loaded in the same time no matter if it is sequentially or
progressively encode so at best a sequential JPEG containing text can claim
that the first lines get readable earlier.

------
codezero
Also, FYI, most Unix-like systems have a correct 'magic' file so that running
the command: file filename.jpg will say whether or not the image is
progressive.

~~~
billyhoffman
Patrick's tool is far more than an boolean "is this a progressive JPEG or
not." Comparing it to the "file" utility is a gross underestimate.

It takes a JPEG, converts it to a progressive JPEG, and then uses an animation
to show you how that image will look loading as a progressive JPEG vs loading
as a the original JPEG. You can see, for example, after 0.5 seconds, how does
the progressive JPEG look vs. how much of the original JPEG is rendered?

This is incredibly powerful and helpful for people focused on frontend web
performance

Comparing this to "file" is l

~~~
codezero
That would be great information for the author to include on the page :) I was
going on the title and what I saw on the page.

~~~
infogulch
Maybe a better title would be "Comparing JPG Progressive Rendering to the
Original Image"

------
teddyh
Is it only me who is annoyed by “JPG”? It’s _JPEG_. I mean, you don’t write
“HTM” files, do you?

~~~
pornel
If you want to be pedantic, the image format is actually called JFIF (JPEG
File Interchange Format). It's been designed _by_ the JPEG (Joint Photographic
Experts Group).

~~~
teddyh
Yes, but the _file extension_ has always been _.jpeg_.

