Legacy ImageMagick Discussions Archive

(Warning: I only looked at this quickly. Working to a tight deadline, and I'm using direct cjpeg calls because I rely on customized progressive scan scripts.)
Take the logo_sample.jpg image for example, and look at the result ofWith bleeding edge IM6 or IM7, compiled in HDRI or Q16, the colour is sucked out of the red letters, almost but not quite as if Chroma subsampling was turned on.
Inspecting with djpeg does not reveal anything significant.
I understand that I can't expect a "perfect" copy when sucking a JPEG into ImageMagick (note that the image is smaller than 500x500, so -resize 500x500\> is a no-op). But the size of the difference is surprising me. A lot. -define jpeg:dct-method=float does not help here.
No surprise with png.
Again: I'm not sure it's a bug. But being that far off even in HDRI mode, in IM6 and IM7 both, is surprising.
Am I missing something (besides possibly underestimating the destructive power of a JPEG toolchain)?

Note: No need to educate me on how to use other tools than IM to do lossless JPEG manipulation: I know.

We don't support a preserve-settings define. What were you expecting it to do?

This explains a lot! I found this in http://www.imagemagick.org/Usage/formats/#jpg_write.
What I was hoping it would do is basically this:
Figure out what sampling-factor, quantization table, and whatever else can be extracted from the input jpg, and use it to compress the output JPEG.
This way, in HDRI and using -dct float, the output should resemble the input reasonably well if no resize occurs.

The documentation is out-of-date. We preserve sampling factor and image quality but not the quantization tables.

Ah! Thank you Cristy.

magick wrote:The documentation is out-of-date. We preserve sampling factor and image quality but not the quantization tables.

Updated.

magick wrote: ↑2013-05-12T11:39:21-07:00 The documentation is out-of-date. We preserve sampling factor and image quality but not the quantization tables.

The Usage page https://www.imagemagick.org/Usage/formats/#jpg_write still hasn't got it quite right IMHO, as it skips the point that these settings are kept automatically.

However: Why isn't there an option to keep the quantization tables? Wouldn't that be the least intrusive approach?

What would you like the documentation to say?

It is a little confusing as to what exactly the option does. It sounds like the setting is 'true' by default. Does setting it to 'false' disable the preservation? Or does the option just not do anything at all?

Or should I just mention those settings are preserved, and quantization tables aren't at the top, and remove the define all together!

I think that only the programmers could really answer that question. My impression is that this option just does nothing at the moment. Perhaps one could re-define it in a way that it really does what it claims, i.e. leaving everything, including the DQTs, untouched.

Checking out the other options, I could confirm, that IM switches off chroma subsampling at qualities of 90% and above – which is a rather unexpected thing to do for my taste. I don't think that this is the default behaviour of the JPEG library, as Gimp and IrfanView, which also use the IJG library, behave differently. And all digital cameras still use chroma subsampling at quality levels of 95% an above.

The only program I know of that automatically switches off chroma subsampling at a certain quality level is Adobe Photoshop, at step 7 (https://www.impulseadventure.com/photo/ ... r-web.html).

I have removed (HTML Commented) the define from IM Examples. It will update, during normal distribution.