reading ImageInfo or encoders that use it

[tc33]

Version: 6.8.0.2

At first, there was an issue that caught my eye. I am using magick++, but am able to recreate an example of the issue with this command:

Code: Select all

convert.exe progressive.jpg nonprogressive.jpg

This turns a progressive JPEG into a non-progressive JPEG. Verified before and after with identify.exe -verbose, Interlace property.

As I dug deeper into the IM internals, I discovered that there is an issue, but I don't know where the problem lies. It's either one of two issues (or both):
1- there doesn't seem to be a way to read/populate an ImageInfo struct for an image, unless the user ( me ) does it manually by reading Image values and setting the appropriate ImageInfo property.
2- some encoders (in this case, JPEG) use the ImageInfo struct to determine how to write the file. However, since the ImageInfo struct never seems to be populated unless I do it manually, a simple command (like the one I posted above) corrupts/changes the image unexpectedly. In debugging, I can see that the Image* contains the correct info, but the ImageInfo* has the wrong data (I'm assuming the values are ImageInfo defaults). And since the JPEG encoder uses the ImageInfo struct for it's decision-making, its writing the incorrect values. Example: jpeg.c, line 2171, for the progressive property.

So, should the image encoders use the Image pointer, or should they use the ImageInfo pointer? If the answer is the former, then jpeg.c is wrong. If the answer is the latter, how does a programmer like me reliably populate the ImageInfo struct based on an Image? And why doesn't convert.exe do it? ( I'm assuming the same problem applies to the other utility programs, since they all share the same code ). It appears as though SyncImageSettings copies ImageInfo to an image, but there doesn't seem to be a method to do the reverse.

Please advise, thanks!

[tc33]

Bigger-picture issues aside, I'd recommend the following changes to solve the interlace problem:

image.c, line 1281:

from:
image_info->interlace=NoInterlace;

to:
image_info->interlace=UndefinedInterlace;

jpeg.c, line 2172:

from:

Code: Select all

  if ((LocaleCompare(image_info->magick,"PJPEG") == 0) ||
      (image_info->interlace != NoInterlace))

to:

Code: Select all

  if ((LocaleCompare(image_info->magick,"PJPEG") == 0) ||
      (image_info->interlace == JPEGInterlace) || 
	  ( (image_info->interlace == UndefinedInterlace) && (image->interlace != NoInterlace) ) 
	  )

However changing the ImageInfo default interlace to UndefinedInterlace ( in image.c ) might mess up other encoders as well.

[glennrp]

Don't change the source code, just use a commandline option or subformat:

Code: Select all

convert.exe progressive.jpg PJPEG:pjpeg_progressive.jpg
convert.exe progressive.jpg -interlace plane plane_progressive.jpg

[tc33]

Glenn, thanks for the response.

I'm doing image manipulation through code; I just provided a simple command line to illustrate the problem. Moreover, I wouldn't necessarily know if the input JPEG was progressive or not, so I couldn't just hard-code in a static value.

I've already come up with a workaround for my app, but the fundamental issue within IM remains. I happened to stumble across the progressive JPEG issue, which leads me to wonder how much more image information is being discarded with every simple read/write across all of the formats? AFAICT, any encoder/writer method which uses the ImageInfo struct is potentially affected.