-function Polynomial 0.123(how many places supported?)456

[gregaiken]

i am having trouble using the

convert in.jpg -function Polynomial 0.123(how many digits are actually supported by convert?)325,0.1234567890123456789012325,0.12345678901234567890123250.1234567890123456789012325 out.jpg

function. the example above shows arbitrary polynomial coefficients.
the convert function does work, but the results i obtain are not at all what i expected.

can anyone state categorically how many digits to the right of the decimal point the convert program is actually able to accurately process?

i dont know where to find this answer in the imagemagick documentation.

i am thinking that perhaps since the precision ive requested may superceed the number of digits that convert will actually recognize - this might be the simple explanation as to why the results are not what i expected.

floating point precision is always something to consider when passing in vars with a high degree of precision - and i expect 'convert' is not immune from this problem. i thought i would start here with my first question.

[fmw42]

You can set the precision to what you might want (within limits of about 15 significant digits, I believe) using -precision. See http://www.imagemagick.org/script/comma ... #precision and http://www.imagemagick.org/Usage/basics/#precision.

However, this is likely limited to printing and not to specifying values. One of the IM developers will need to respond.

I suspect IM computations are full floating point values if not doubles.

But will you really see any visual difference from 6 significant digits (the default)?

[snibgo]

I doubt that giving more decimal places than can be used will give problems. I suggest you paste the exact command that is given. In your bold text, you are missing a comma, and that will give problems.

[gregaiken]

ive posted a clear to follow step-by-step procedure of how i came to derive the required coefficients, and the exact command i ran, as well as providing a link to the sample image (these coefficients were designed for).

the document is a bit long, and includes a number of embedded images, so ive posted it at my personal web page...

http://gregaiken.com/misc/imagemagick_problem1/

it would really be great if someone can figure out why this 'convert -function Polynomial' function isn't doing what it should be doing - as i really have come to rely on ImageMagick for many image processing functions. This is the first time I've had trouble getting ImageMagick to behave properly.

thanks for any insights,

greg

[snibgo]

See http://www.imagemagick.org/script/comma ... p#function:

... where u is pixel's original normalized channel value.

"Normalized" means the value is 0.0 to 1.0, not 0.0 to 255.0. To calculate ABCD, use 123/255 etc.

[gregaiken]

Thank you SO MUCH snibgo !

I imagined this was most probably somehow my fault. I did not realize the pixel values needed to be rescaled to be in between 0 and 1.

ill go back to the drawing board and try this again.

again thanks for the suggestion.

[gregaiken]

i am just reporting that this proved to be the problem!
once i recalculated my coefficients to work with pixel values having a range of 0 to 1,
then plugged those new coefficients into the convert function,
things worked perfectly!
so imagemagick had no trouble using all of those digits to the right of the decimal afterall.
again thanks to the user who pointed me in the right direction!

[snibgo]

Good stuff. ImageMagick, like any image processing system, uses a number of different units for different purposes, eg scaled as 0 to 1, 0 to 100, 0 to Quantum.

IM may not use all the digits to the right of the decimal. Perhaps just the first 15 or so; it will depend on the datatype of the C variable. But any extra should cause no problem.

[snibgo]

If we really want to know how many digits are accepted, we can easily find out. The answer depends on the Q of IM, and whether HDRI:

Code: Select all

f:\web\im>%IM16i%convert -precision 25 xc: -function polynomial 0.1234567890123456789012345 txt:
# ImageMagick pixel enumeration: 1,1,65535,srgb
0,0: (12.34607461661707539235522%,12.34607461661707539235522%,12.34607461661707539235522%)  #1F9B1F9B1F9B  srgb(12.34607461661707539235522%,12.34607461661707539235522%,12.34607461661707539235522%)

f:\web\im>%IM32i%convert -precision 25 xc: -function polynomial 0.1234567890123456789012345 txt:
# ImageMagick pixel enumeration: 1,1,4294967295,srgb
0,0: (12.34567889765502890497828%,12.34567889765502890497828%,12.34567889765502890497828%)  #1F9ADD371F9ADD371F9ADD37  srgb(12.34567889765502890497828%,12.34567889765502890497828%,12.34567889765502890497828%)

f:\web\im>%IM32f%convert -precision 25 xc: -function polynomial 0.1234567890123456789012345 txt:
# ImageMagick pixel enumeration: 1,1,4294967295,srgb
0,0: (12.34567890123456734841056%,12.34567890123456734841056%,12.34567890123456734841056%)  #1F9ADD371F9ADD371F9ADD37  srgb(12.34567890123456734841056%,12.34567890123456734841056%,12.34567890123456734841056%)