Legacy ImageMagick Discussions Archive

I'm using ImageMagick in cinemaslides (http://github.com/wolfgangw/digital_cin ... nemaslides) to conform, resize, recolor etc. images and to create DCP slideshows. Chasing an issue with image quality degradation (with rather dark zones/material) I wondered what's going on here (simplified version):

Code: Select all

$ convert -depth 8 -size 600x600 gradient: gradient.tif

What I used to do:

Code: Select all

$ convert gradient.tif -gamma 0.454545454545455 -depth 8 -gamma 2.2 decode_depth_encode.tif

This fixed the issue:

Code: Select all

$ convert gradient.tif -gamma 0.454545454545455 -gamma 2.2 -depth 8 decode_encode_depth.tif
$ identify *
decode_depth_encode.tif TIFF 600x600 600x600+0+0 8-bit Grayscale DirectClass 352KiB 0.000u 0:00.000
decode_encode_depth.tif[1] TIFF 600x600 600x600+0+0 8-bit Grayscale DirectClass 352KiB 0.000u 0:00.000
gradient.tif[2] TIFF 600x600 600x600+0+0 8-bit Grayscale DirectClass 352KiB 0.000u 0:00.000
$ display *

The results seem to suggest that doing gamma decode -> depth -> gamma encode cuts off internal precision. But, actually, I don't get it. Thanks in advance for hints and explanations.

Also, I feel this is said too rarely: Thanks for the awesome work ImageMagick represents, thanks for sharing it, too.

some commands need to be put in a certain order to function properly. commands are processed generally in linear order, they are not just settings that can be done in any order.

Wolfgang Woehl wrote:The results seem to suggest that doing gamma decode -> depth -> gamma encode cuts off internal precision.

Sure. The gamma operation gives a 16bit result (if you're using a Q16 version of ImageMagick). Setting the depth to 8bit in between lowers the precision. So, use "-depth 8" only at the end of your operations (which you do in your current scripts, as far as I can see) - if you need 8bit files. It also depends a bit on the ImageMagick version. What exact version are you using?

I'm getting the same results with 6.5.7-8 2009-11-26 Q16 (Ubuntu 10.04's default IM) and 6.6.3-0 2010-07-13 Q16

Does -depth truncate/pad or map?

-depth is only a setting that effects the output and writing of image files and information.
Where it is located in this example should have no bearing on the results at all.

Gamma is a basically an inverted power operator. If the two gamma values are the inverse of each other (1/x) then the resulting image should be basically equivelent to each other, with the two gammas cancling out each other out. May as well only have -depth present to produce 8 bit values for a 24/32 bit TIFF image.

The only precision problem I can see is that the image is being saved back into 16 bit integers after each gamma operation. Generally this produces small 'bit' errors in the very low (near black) colors, and should not be visible in this example.

The Depth operation does not truncate, just appropriate scaling!

for 16 to 8 bit does a division by the bit difference of 2^(bit_diff)+1. For Im Q16 that bit difference is 8, so it will divide 16bit integer values by 2^8+1 or 129. This ensures that a 16 bit value of 0xFFFF becomes 0xFF so that whites remain whites, and all other colors match up accordingly.

Similarly when reading a 8 bit value image it multiplies by 129, so that a number like 0xC0 becomes 0xC0C0.

In cinemaslides there are a number of ops performed in quasi-linear light (between an approximate gamma decode and a final encode). When the issue came up (hard banding in low-light zones) I tried to isolate the culprit op. Turned out the order of -gamma <encode> and -depth makes all the difference. You say IM's depth reduction is scaling so I think I understand what's happening. Thanks.

anthony wrote:-depth is only a setting that effects the output and writing of image files and information.
Where it is located in this example should have no bearing on the results at all.

Did you try the example? Even in the above (simplified!) example, one gets the differences (differences that are not restricted to the near-black values). In this example, it's even noticable visually (as Wolfgang says, it can result in banding) - but one could use compare, too...

Code: Select all

convert -depth 8 -size 600x600 gradient: gradient.tif
convert gradient.tif -gamma 0.454545454545455 -depth 8 -gamma 2.2 decode_depth_encode.tif
convert gradient.tif -gamma 0.454545454545455 -gamma 2.2 -depth 8 decode_encode_depth.tif
compare decode_encode_depth.tif decode_depth_encode.tif compared.gif

But, of course, that's nothing unusual - that's the way "-depth" has to work..

@Wolfgang:
In some ImageMagick versions (versions 6.6.0-6 to 6.6.2-3), the loss of precision was greater than needed (I also used some gamma operations to show that effect: viewtopic.php?f=3&t=16265#p59240 ).
But as you're not using one of the mentioned versions, and you've placed "-depth" at the end of your operations, there should be no problem with your scripts now.

2 very interesting threads I had missed completely, thanks.

Legacy ImageMagick Discussions Archive

Internal bit depth and -depth operator

Internal bit depth and -depth operator

Re: Internal bit depth and -depth operator

Re: Internal bit depth and -depth operator

Re: Internal bit depth and -depth operator

Re: Internal bit depth and -depth operator

Re: Internal bit depth and -depth operator

Re: Internal bit depth and -depth operator

Re: Internal bit depth and -depth operator