Follow Slashdot stories on Twitter


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Epeg (Score 1) 29

by Rabid Penguin (#13236519) Attached to: Using Enlightenment 17's Epeg API (Part Deux)
Hold your breath for I shall perform a feat rarely seen on Slashdot... I will actually talk about the subject of the article!

Epeg has one purpose, to scale JPEG images very quickly. One of the primary reasons it was created was because of the thumbnail spec. The spec requires that the thumbnails be stored as PNG's. While experimenting with this, it was found that converting large JPEG's to PNG's was a relatively slow process because of the color space conversions and IDCT. If the spec was extended to allow JPEG thumbnails, then the conversion process can be JPEG to JPEG.

By keeping the formats the same, you can now do the scaling during the jpeg decode (avoid extra pixel traversals scaling the RGB data after it has been decoded), keep JPEG native color space (no YCbCr->RGB conversion, again traversing the pixel data, twice if you go back to non-RGB image data), and reducing the output written to disk in almost every case (because of the end result being a JPEG rather than a PNG).

Overall, it exists because it didn't seem right to not support the most common image format as a thumbnail when it allows for such large speed increases creating the thumbnails and reduced disk space used for meta-data. Just because disks get larger and CPU speeds increase doesn't mean we shouldn't use them wisely, especially when it's less than a days worth of hacking to do so.

"Stupidity, like virtue, is its own reward" -- William E. Davidsen