Anyway, using a different library than libjpeg would not change much: Photoshop cannot use a better (or worse) algorithm, because the JPEG compression algorithm is standardized and has to be implemented in the specific way if you want the files to be readable by any JPEG viewer.

The differences that can be observed between both programs are not related to the algorithm, but to the quantization tables that are used for the JPEG compression. These tables define how much of the original image is kept when saving (specifically, the divisors in these tables influence how many DCT coefficients are kept). Each table contains 64 numbers and is included directly in the JPEG file because it is needed for decompressing the file later. There are usually 2 or 3 quantization tables in the file: one for luminance and one or two for chrominance.

When you select a given “quality level” in GIMP (libjpeg) or in Photoshop, you are asking the program to generate the quantization tables that have been associated with that quality level by its developers. Different programs use different tables, but they usually have many similarities. That’s why I created the tables included in this article: they allow you to find the quantization tables that are similar in both programs.

Considering how JPEG compression works, I would be very surprised if you could find some images that produce better results in Photoshop than in GIMP. What happens is usually the opposite: GIMP saves JPEG files that are smaller than with Photoshop but have the same (or better) quality. One of the simple reasons for that difference is that Photoshop includes more metadata by default.

Is it because Photoshop uses a better algorithm? Perhaps there are any alternatives to libjpeg which can give a better size/quality ratio?

That would be fine if there was also a requirement to make it easy to regenerate the files because then it would be trivial to go back to the “preferred form of the work for making modifications to it”. But this requirement is missing, so it could be exploited by people or companies who want to prevent others from compiling and using some GPLed code.

Anyway, the fact that it says “regenerate” implies that it was generated in the first place. So anything computationally infeasible would be out, since the distributor could not have generated the file using that method in the first place.

http://www.rootshell.be/~loopback/images/preferences.png

Now, the discussion whether it’s better follow the unix-way (do a simple task, and do it well) or not: I don’t think it applies well for graphical inteface. That paradigm is well suited in environments where you can chain several programs easily (think in a pipeline in bash).

For graphical environments, where pipelining is not so easy to achieve, you gotta find a balance between `this IM client is really a text editor, an account manager and a central IM send/receive server that communicates with the other two´ (not that such a nonsense exists) and `this program can burn your dvd’s, do your school exams, feed you children and discuss with your boss about a promotion/salary raise and get it´.

Also, it is obvious that you can’t please everybody. By example, I decided my parents will be using gnome, while I love so much kde and I know it to the bone, because I think that’s better for each one.

More in a rant mode: Given that I love to custom the apps to my needs, I don’t find the use of an external program to fully tweak the programs I use very attractive. Maybe if instead of a separate app, an embeddable widget in the `advanced settings´ page with just the settings for that app…

–
PS: this blog doesn’t have a preview button! where is it?!?