News for hackers. Stuff that matters.
Re:Progressive JPEGs: a new best practice by r0s on Saturday December 29, 2012 @03:34PM (#4983336)
Assuming the image has a small thumbnail embedded in the EXIF data, maybe it would be even faster to use that resource (already included with the image), scaled to fill the image space and replaced when the image loads.

Essentially the same effect, with some back-end code. I suppose we'd need a benchmark test to find the real numbers. The main advantage would be sticking with existing file types already in use.

Re:Progressive JPEGs: a new best practice by reeses on Sunday December 30, 2012 @12:50AM (#4984826)
JPEG already supports multiple images per file. If you add EXIF data with manifest information with web rendering hints at the head, your thumbnail in the next frame, and your full-sized image after, you'd be on the track to awesomesauce.

(I'm sure someone has already implemented something better than this, but I am lazy.)

Re:Progressive JPEGs: a new best practice by quasque on Saturday December 29, 2012 @03:52PM (#4983412)
On that note it would be interesting to see if the EXIF data is typically included at the start or end of JPEG files, or if it varies via compressor.
Re:Progressive JPEGs: a new best practice by jzwinck on Sunday December 30, 2012 @05:50AM (#4985367)
In EXIF, whether applied to JPEG or TIFF, the header comes first, then the thumbnail if present, then the primary image. Exactly as you'd want (which is more than can be said for much of EXIF, e.g. that it lacks time zone encodings).
Re:Progressive JPEGs: a new best practice by neumann_alfred on Saturday December 29, 2012 @06:23PM (#4983877)
Then it would still be even faster in total if you do the same thing with progressively encoded images.