This project has moved and is read-only. For the latest updates, please go here.

Detect compression method with MagickImageInfo

Oct 30, 2015 at 3:37 PM
We have a "fixing" process that sanitizes images for our purposes and we use MagickImageInfo to determine whether a fix is necessary since it's fast. An image was sent to us that uses run length compression (which I believe is RLE in CompressionMethod enum but correct me). It appears this type of compression doesn't work with GDI+ so it's a candidate for fixing. The problem is since this was a JPG, and if only MagickImage could be used to know it, I would have to load all JPG's to see if they had this type of compression.

Is it possible to detect the compression method of a JPG image with MagickImageInfo so we don't have to load the entire image? Does Ping have other methods that might help with this?

Oct 30, 2015 at 4:32 PM
Edited Oct 30, 2015 at 4:33 PM
You can use the Ping method of MagickImage to read only the basic information of an image. This is kind of what the MagickImageInfo class does. I will add a Compression property to the MagickImageInfo class in the next release.

But I don't think that pinging a MagickImage and then reading the compression property will help you. The compression property is never set to RLE in the jpeg decoder of Magick.NET.

It might be possible that your GDI+ issue gone when you lossless compress the image ( Maybe you should give that a try? This will really reduce the size of your file also!
Oct 30, 2015 at 4:44 PM
If MagickImageInfo can determine the Compression without loading the entire image, that will solve the issue. Then I will be able to know that this image should be processed further. These images come from our customers and we have no idea what will be in them. Consequently, if something is "wrong" with the image for our purposes, loading only the headers to decide is the most efficient way.

We have a vendor/third-party rendering program that uses GDI+ to read images and is a black box. So, I have to fix these images before that process tries to use the image. If I understand your last paragraph, detecting the Compression beforehand avoids a catch-22 -- it's too inefficient to read the entire image all the time (since JPG is what we get the most) and as you indicate earlier it wouldn't matter if I read it because there's nothing to detect with compression before decoding.

Hope that makes sense, and thanks for your help.
Oct 30, 2015 at 5:33 PM
Edited Oct 30, 2015 at 5:33 PM
I am sorry but I think I have not explained it clearly enough. What I meant is that the compression is not set to RLE at any point when reading or pinging the JPEG image.

An other option could be converting your JPEG image to another format like BMP or TIFF before you send the image to your third-party application.

I think you have another issue then Compression but I am guessing that you are just getting an out of memory error that does not tell you anything. Feel free to contact me through CodePlex to share some more information if you don't want to share it publicly.
Oct 30, 2015 at 6:03 PM
Edited Oct 30, 2015 at 6:09 PM
Ok - more investigation confirms your suspicion. The image is large on disk and GDI+ is unable to open it (OOM exception), although the size is a reasonable 4000x6000. When I save over the image using 100% quality with irfanview, GDI+ is able to open it again. The only big difference between the saves is the number of unique colors is cut roughly in half; the size in memory is the same. There could be other things going on, but I don't know enough about imaging to know.

I suspect this is just GDI+ and its bad error messages. If you would like one of the images to investigate, I can send one but don't want to waste your time with a GDI+ issue. False alarm, but thanks for the discussion.
Oct 31, 2015 at 10:11 AM
Could you contact me through CodePlex with a link to the original image and the one saved in irfanview?

Are you still trying to automate the 'fixing' of images that cannot be handled by your third party application? And have you checked if those failing images are CMYK instead of RGB?
Nov 6, 2015 at 5:04 PM
I have replied to your e-mail that you send through CodePlex. Did you get this message?
Nov 6, 2015 at 6:26 PM
Hello. I was finally able to modify the "fixing" code and test it out. You were correct on all fronts and it now converts Sgi images back to JPEG before storage. I should have checked the Format with Magick.NET, but was too focused on the compression.

The conversion to JPEG does remove a good portion of the unique colors (over half) even at 100% compression. I'm well aware of how JPEG is (almost) never a lossless conversion so in the future we might consider supporting PNG in our work flow.

So to wrap this up, even though it's not really relevant now - is there a way to get the Compression method of a source JPEG image through a shallow read like MagickImageInfo? It likely becomes meaningless once the image is loaded since it's a bitmap by that point, but maybe it would have some use in the future if it's possible.

Nov 8, 2015 at 9:50 PM
The compression of your JPEG image will always be set CompressionMethod.JPEG but it does make sense to have the compression available in the MagickImageInfo class. I just pushed a patch to add this feature and this will be available in the next release of Magick.NET (