possible bug -precision IM 6.6.3.4 HDRI

[fmw42]

Perhaps I am misunderstanding how to use -precision. But this does not seem to work:

convert xc: -precision 3 -format "%[fx:pi]" info:
3.14159

Am I not using this correctly?

[anthony]

It just hasn't been applied to -fx as yet. I noticed this when it was first added while I was in china.

I have also still to add precision to distort verbose output, and to resize filter debug output too.

It has been added to debug morphology kernel output.

For %[fx:...] I would prefer to see something better than just precision for its output control.
For example a proper printf() format so I can specify things like %05d to get fx to output a 5 digit number with leading zeros.

Actually a better -precision control than just a simple number would have been even better, though harder to implement.

EG: -precision %10.5f would have been more preferable than just '5'
But then I was not available at the time it was implemented.

[fmw42]

This works.


convert xc: -precision 3 -fx "debug(3.123456789012345)" null:
[0,0].red: 3.123456789012345=3.12
[0,0].green: 3.123456789012345=3.12
[0,0].blue: 3.123456789012345=3.12


But per a private email to Magick, it was supposed to be added to:

1) fx calculations
2) string formats such as min, max, mean, std (and I guess the newer ones like kurtosis)
3) stats in -verbose info

However, I failed to follow up on testing those after replying with the above (1/17/10)

[fmw42]

This now works in IM 6.6.3.6 Q16 HDRI

1)
convert xc: -precision 3 -format "%[fx:pi]" info:
3.14

And this works:

convert rose: -depth 8 -precision 3 -format "%[fx:255*mean]" info:
146


But the following does not seem to work to the correct precision. Is precision decimal precision or significant digits precision? In either case the first example below is wrong.

Also should not the -depth 8 affect the result or is it always in the range 0 to QuantumRange irrespective of the depth? Also why is it showing in scientific notation and not just decimal values, which one gets if no precision is specified? Is that because one needs to convert to scientific notation to show appropriate decimal precision?

2)
convert rose: -depth 8 -precision 3 -format "%[mean]" info:
2.7e+04

whereas

convert rose: -format "%[mean]" info:
27022.8

likewise:

3)
convert rose: -precision 3 -set filename:mean "%[mean]" 'rose_%[filename:mean].png'

produces rose_2.7e+04.png (but this is not 3 decimals)

whereas

convert rose: -set filename:mean "%[mean]" 'rose_%[filename:mean].png'

produces rose_27022.8.png

So I guess one needs to convert to scientific notation to be able to set proper precision for string formats due to the size of the values.


and

4)
convert rose: -set filename:mean "%[fx:100*mean]%" rose_%[filename:mean].png
produces rose_57.142%.png

But

convert rose: -set filename:mean -precision 1 "%[fx:100*mean]%" rose_%[filename:mean].png
or
convert rose: -precision 1 -set filename:mean "%[fx:100*mean]%" rose_%[filename:mean].png

Both give error messages:

[magick]

So I guess one needs to convert to scientific notation to be able to set proper precision for string formats due to the size of the values.

We use %g format which uses the shorter of %e or %f where %e is scientific notation (mantise/exponent) and %f is decimal floating point. In certain cases we could switch to %f instead of %g if that makes more sense.

Both give error messages:

Try this command:

• convert rose: -precision 1 -set filename:mean "%[fx:100*mean]%" 'rose_%[filename:mean].png'

[fmw42]

Try this command:

• convert rose: -precision 1 -set filename:mean "%[fx:100*mean]%" 'rose_%[filename:mean].png'

Yes, that works:

rose_6e+01%.png


So the trick is to enclose the resulting image in quotes?

But from above:

convert rose: -precision 3 -set filename:mean "%[mean]" 'rose_%[filename:mean].png'

produces rose_2.7e+04.png

But this is not 3 significant digits (only 2). Should it not be 2.70e+4 or is that standard to drop trailing zeros,even if there are non-zero digits following the zero, since

convert rose: -set filename:mean "%[mean]" 'rose_%[filename:mean].png'

produces rose_27022.8.png (so 2.70228e+4)

[magick]

But this is not 3 significant digits (only 2

You'll need to file a bug report with the maintainers of the C standard library. You can reproduce the results with this code:

Code: Select all

#include <stdio.h>
main()
{
  printf("%0.3g\n"27022.751863354,);
}

Now compile and execute:

• cc format.c
  a.out
  2.7e+04

[fmw42]

Thanks for the reply. I will assume that in C, zeros get truncated as standard procedure.


convert xc: -precision 3 -format "%[fx:27002.7]" info:
2.7e+04


and



convert xc: -precision 3 -format "%[fx:27100.0]" info:
2.71e+04