I wonder what the difference would really be by having a different quantum depth when compiling with HDRI support. If I'm not totally mistaken, the internal precision would be 32-bit floats no matter what the quantum depth is set to. Is it safe to assume that it mostly only affects stuff like the range of the return value from PixelGetGreenQuantum() and such?
Will the "Quantum" type be typedef'ed to a 16-bit integer when --enable-hdri is defined, or will it use IEEE floats?
Practical or theoretical difference with Q8/Q16/Q32 and HDRI
-
anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: Practical or theoretical difference with Q8/Q16/Q32 and
Basically having a Quantum Depth in HDRI is only so that any algorithms that rely on having integers stored in images, will work as expected.
Examples of such algorithms include 'Morphology Distance' functions that is meant to return some type of integer value. Of course IM's distance function is set up to use 'fix-width point' math of 100 units per pixel distance so that you can get at least some floating point precision in a non-HDRI Q16 version of IM. IM users using a Q8 version would more likely need to switch to a less precise integer or near-integer distance function (Like Octagon).
Morphology Distance
http://www.imagemagick.org/Usage/morphology/#distance
Using images to hold 'index' values is another example where some 'quantum depth' is needed even in HDRI versions of IM.
For an example of this see RubbleWeb's Web ImageMap 'user select' technique
http://www.rubblewebs.co.uk/imagemagick ... allery.php
Some other 'lookup tables in an image' also probably relies on exact quantum integers, rather than inexact floating point. a Quantuam Depth just makes it much easier to handle.
That are just some techniques where have a quantum depth is important. Some internal algorithms also probably require it (I think contrast/level stretch operators need it), but I am not exactly certain which operators.
Note: Many times I have had to muck around with FX formula, as it only provides image values as normalized floating point values. I would like to see a FX mode or access that returns actual image 'quantum' values instead of normalized values.
This gets worse when the value I needed is not the normalized 0 to 1 value, but a 0 to 'almost 1'. That is, the lookup up image value is divided by QuantumRange+1, rather than just QuantumRange).
For an example of this see Dithering with Symbol Patterns
http://www.imagemagick.org/Usage/quantize/#diy_symbols
where I multiply the normalized value by a 'N.9999999' to get (very roughly) the right lookup index range needed.
Examples of such algorithms include 'Morphology Distance' functions that is meant to return some type of integer value. Of course IM's distance function is set up to use 'fix-width point' math of 100 units per pixel distance so that you can get at least some floating point precision in a non-HDRI Q16 version of IM. IM users using a Q8 version would more likely need to switch to a less precise integer or near-integer distance function (Like Octagon).
Morphology Distance
http://www.imagemagick.org/Usage/morphology/#distance
Using images to hold 'index' values is another example where some 'quantum depth' is needed even in HDRI versions of IM.
For an example of this see RubbleWeb's Web ImageMap 'user select' technique
http://www.rubblewebs.co.uk/imagemagick ... allery.php
Some other 'lookup tables in an image' also probably relies on exact quantum integers, rather than inexact floating point. a Quantuam Depth just makes it much easier to handle.
That are just some techniques where have a quantum depth is important. Some internal algorithms also probably require it (I think contrast/level stretch operators need it), but I am not exactly certain which operators.
Note: Many times I have had to muck around with FX formula, as it only provides image values as normalized floating point values. I would like to see a FX mode or access that returns actual image 'quantum' values instead of normalized values.
This gets worse when the value I needed is not the normalized 0 to 1 value, but a 0 to 'almost 1'. That is, the lookup up image value is divided by QuantumRange+1, rather than just QuantumRange).
For an example of this see Dithering with Symbol Patterns
http://www.imagemagick.org/Usage/quantize/#diy_symbols
where I multiply the normalized value by a 'N.9999999' to get (very roughly) the right lookup index range needed.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/