Problems With IM 6.4.0-3 and 6.4.0-7 both Q16 HDRI
Posted: 2008-04-19T18:39:38-07:00
Hi,
While testing Sean Burke's FFT routines in IM 6.4.0-3 Q16-hdri, I ran into several issues that I wanted to bring to your attention. See note at bottom as I cannot get the FFT to run under IM 6.4.0-7 and had to back down to IM 6.4.0-3.
1. I have an image that represents the magnitude of the FFT of a motion blur spatial filter.
(The spatial blur filter before the FFT can be viewed at
http://www.fmwconcepts.com/misc_tests/F ... lt_h15.png
It is just a 15x1 pixel white line in a black background)
The magnitude image will be very dark as it has very small values. The DC (center point), which will be the largest valued pixel, will have a value that is the average of the original image, which is mostly black, thus a very small value. The magnitude is stored in MIFF format to preserve the small floating point values. The magnitude of the FFT of a 15x1 pixel constant-value line should be a sinc function in the horizontal direction. So I wanted to scale the image for viewing and to make a profile to check it out.
Here is the magnitude image:
http://www.fmwconcepts.com/misc_tests/F ... fft-0.miff
I therefore used -contrast-stretch 0% to stretch the image linearly to make the minimum value go to 0 and the maximum value go to quantum-max. Please correct me if I misunderstand what -contrast-stretch 0% is supposed to do. I then used my profile script to plot the profile. (You can get my profile script at http://www.fmwconcepts.com/imagemagick/index.html, if you desire).
Here is the resulting profile:
http://www.fmwconcepts.com/misc_tests/F ... rofile.gif
Note that the peaks are clipped flat. This implies to me that in HDRI, -contrast-stretch 0% is NOT preserving the floating point values properly.
Therefore, to verify that assumption, I scaled the magnitude by getting the minimum and maximum values from -verbose info and used -fx. This produced a proper looking profile:
http://www.fmwconcepts.com/misc_tests/F ... rofile.gif
So the question is should -contrast-stretch 0%, when used in Q16-hdri environment, preserve the floating point values properly while scaling. If it should, can you look into correcting this?
2) I have another image which is just a white 31x31 square in a black background.
http://www.fmwconcepts.com/misc_tests/F ... uare31.png
I did an FFT on this and wanted to look at the phase image. This image will have values that range within -pi to +pi (-3.14 to +3.14). Thus they are extremely small values in a Q16 environment, even with HDRI. I wanted to scale this image for viewing, but ran into trouble using both bc and fx to compute the scaling coefficients, because they get reported by IM fx in scientific numbers (after dividing by quantum-max) and computing the difference gives meaningless numbers. Here is the unscaled phase image:
http://www.fmwconcepts.com/misc_tests/F ... fft-1.miff
If I scale it using -contrast-stretch 0%, I get:
http://www.fmwconcepts.com/misc_tests/F ... -1_cs0.png
which shows diagonal banding that should not be there.
So I attempted to get the scaling values to use with -fx as follows:
from -verbose info I got:
min: -3.12932 (-4.77504e-05)
max: 3.12932 (4.77504e-05)
But when I tried to automate this as follows, I got:
freds-mac-mini:~ fred$ config=`convert -list configure`
freds-mac-mini:~ fred$ quantum=`echo "$config" | sed -n 's/^QuantumDepth[ ]*\([0-9]*\)$/\1/ p'`
freds-mac-mini:~ fred$ qmax=`echo "scale=0; (2^$quantum - 1) / 1" | bc`
freds-mac-mini:~ fred$ echo "qmax=$qmax"
qmax=65535
freds-mac-mini:~ fred$ min=`convert $phase -format "%[min]" info:`
freds-mac-mini:~ fred$ max=`convert $phase -format "%[max]" info:`
freds-mac-mini:~ fred$ min=`convert xc: -format "%[fx:$min/$qmax]" info:`
freds-mac-mini:~ fred$ max=`convert xc: -format "%[fx:$max/$qmax]" info:`
freds-mac-mini:~ fred$ diff=`convert xc: -format "%[fx:($max-$min)]" info:`
freds-mac-mini:~ fred$ echo "min=$min"
min=-4.77504e-05
freds-mac-mini:~ fred$ echo "max=$max"
max=4.77504e-05
freds-mac-mini:~ fred$ echo "diff=$diff"
diff=15.9598
Note the min and max values are reported in agreement with -verbose info, but the diff is nonsense. I assume this occurs because min and max are in scientific notation and -fx perhaps cannot handle that as input values. Can you confirm if this should work or not? If it should, can this be easily fixed.
To confirm, I therefore did the following by re-expressing the values as decimal values:
freds-mac-mini:~ fred$ min=-0.0000477504
freds-mac-mini:~ fred$ max=0.0000477504
freds-mac-mini:~ fred$ diff=`convert xc: -format "%[fx:($max-$min)]" info:`
freds-mac-mini:~ fred$ echo "diff=$diff"
diff=9.55008e-05
Which now reports the difference correctly.
Therefore, I converted this diff to decimal value and used the min in decimal value to do the scaling in -fx:
convert $phase -fx "(u+0.0000477504)/0.0000955008" square31_fft-1_csfx.png
which produced the following smooth and correctly scaled phase image:
http://www.fmwconcepts.com/misc_tests/F ... 1_csfx.png
(Note: I believe that I can use -evaluate in place of -fx to do the scaling as the former uses values 0 to quantum-max rather than 0 to 1 and therefore the values reported by -fx for the min and max of the image using %[min] and %[max] need not be divided by quantum-max. Therefore the diff should be properly computed.)
Nevertheless, the bottom line is that there are two issues:
1) -contrast-stretch 0% is not preserving the floating point values properly while scaling in an HDRI configuration.
2) -fx calculations do not seem to work with scientific notation variables
Thanks.
Fred
P.S.
I have not been able to get Sean's same FFT routine to work in IM 6.4.0-7. It hangs while trying to read the image. He is looking further into it. But I was wondering if you know of anything that might have changed since IM 6.4.0-3 that might be causing this. (Perhaps something to do with another change with Ghostscript, as with a previous problem that Sean reported just before IM 6.4.0-3)
While testing Sean Burke's FFT routines in IM 6.4.0-3 Q16-hdri, I ran into several issues that I wanted to bring to your attention. See note at bottom as I cannot get the FFT to run under IM 6.4.0-7 and had to back down to IM 6.4.0-3.
1. I have an image that represents the magnitude of the FFT of a motion blur spatial filter.
(The spatial blur filter before the FFT can be viewed at
http://www.fmwconcepts.com/misc_tests/F ... lt_h15.png
It is just a 15x1 pixel white line in a black background)
The magnitude image will be very dark as it has very small values. The DC (center point), which will be the largest valued pixel, will have a value that is the average of the original image, which is mostly black, thus a very small value. The magnitude is stored in MIFF format to preserve the small floating point values. The magnitude of the FFT of a 15x1 pixel constant-value line should be a sinc function in the horizontal direction. So I wanted to scale the image for viewing and to make a profile to check it out.
Here is the magnitude image:
http://www.fmwconcepts.com/misc_tests/F ... fft-0.miff
I therefore used -contrast-stretch 0% to stretch the image linearly to make the minimum value go to 0 and the maximum value go to quantum-max. Please correct me if I misunderstand what -contrast-stretch 0% is supposed to do. I then used my profile script to plot the profile. (You can get my profile script at http://www.fmwconcepts.com/imagemagick/index.html, if you desire).
Here is the resulting profile:
http://www.fmwconcepts.com/misc_tests/F ... rofile.gif
Note that the peaks are clipped flat. This implies to me that in HDRI, -contrast-stretch 0% is NOT preserving the floating point values properly.
Therefore, to verify that assumption, I scaled the magnitude by getting the minimum and maximum values from -verbose info and used -fx. This produced a proper looking profile:
http://www.fmwconcepts.com/misc_tests/F ... rofile.gif
So the question is should -contrast-stretch 0%, when used in Q16-hdri environment, preserve the floating point values properly while scaling. If it should, can you look into correcting this?
2) I have another image which is just a white 31x31 square in a black background.
http://www.fmwconcepts.com/misc_tests/F ... uare31.png
I did an FFT on this and wanted to look at the phase image. This image will have values that range within -pi to +pi (-3.14 to +3.14). Thus they are extremely small values in a Q16 environment, even with HDRI. I wanted to scale this image for viewing, but ran into trouble using both bc and fx to compute the scaling coefficients, because they get reported by IM fx in scientific numbers (after dividing by quantum-max) and computing the difference gives meaningless numbers. Here is the unscaled phase image:
http://www.fmwconcepts.com/misc_tests/F ... fft-1.miff
If I scale it using -contrast-stretch 0%, I get:
http://www.fmwconcepts.com/misc_tests/F ... -1_cs0.png
which shows diagonal banding that should not be there.
So I attempted to get the scaling values to use with -fx as follows:
from -verbose info I got:
min: -3.12932 (-4.77504e-05)
max: 3.12932 (4.77504e-05)
But when I tried to automate this as follows, I got:
freds-mac-mini:~ fred$ config=`convert -list configure`
freds-mac-mini:~ fred$ quantum=`echo "$config" | sed -n 's/^QuantumDepth[ ]*\([0-9]*\)$/\1/ p'`
freds-mac-mini:~ fred$ qmax=`echo "scale=0; (2^$quantum - 1) / 1" | bc`
freds-mac-mini:~ fred$ echo "qmax=$qmax"
qmax=65535
freds-mac-mini:~ fred$ min=`convert $phase -format "%[min]" info:`
freds-mac-mini:~ fred$ max=`convert $phase -format "%[max]" info:`
freds-mac-mini:~ fred$ min=`convert xc: -format "%[fx:$min/$qmax]" info:`
freds-mac-mini:~ fred$ max=`convert xc: -format "%[fx:$max/$qmax]" info:`
freds-mac-mini:~ fred$ diff=`convert xc: -format "%[fx:($max-$min)]" info:`
freds-mac-mini:~ fred$ echo "min=$min"
min=-4.77504e-05
freds-mac-mini:~ fred$ echo "max=$max"
max=4.77504e-05
freds-mac-mini:~ fred$ echo "diff=$diff"
diff=15.9598
Note the min and max values are reported in agreement with -verbose info, but the diff is nonsense. I assume this occurs because min and max are in scientific notation and -fx perhaps cannot handle that as input values. Can you confirm if this should work or not? If it should, can this be easily fixed.
To confirm, I therefore did the following by re-expressing the values as decimal values:
freds-mac-mini:~ fred$ min=-0.0000477504
freds-mac-mini:~ fred$ max=0.0000477504
freds-mac-mini:~ fred$ diff=`convert xc: -format "%[fx:($max-$min)]" info:`
freds-mac-mini:~ fred$ echo "diff=$diff"
diff=9.55008e-05
Which now reports the difference correctly.
Therefore, I converted this diff to decimal value and used the min in decimal value to do the scaling in -fx:
convert $phase -fx "(u+0.0000477504)/0.0000955008" square31_fft-1_csfx.png
which produced the following smooth and correctly scaled phase image:
http://www.fmwconcepts.com/misc_tests/F ... 1_csfx.png
(Note: I believe that I can use -evaluate in place of -fx to do the scaling as the former uses values 0 to quantum-max rather than 0 to 1 and therefore the values reported by -fx for the min and max of the image using %[min] and %[max] need not be divided by quantum-max. Therefore the diff should be properly computed.)
Nevertheless, the bottom line is that there are two issues:
1) -contrast-stretch 0% is not preserving the floating point values properly while scaling in an HDRI configuration.
2) -fx calculations do not seem to work with scientific notation variables
Thanks.
Fred
P.S.
I have not been able to get Sean's same FFT routine to work in IM 6.4.0-7. It hangs while trying to read the image. He is looking further into it. But I was wondering if you know of anything that might have changed since IM 6.4.0-3 that might be causing this. (Perhaps something to do with another change with Ghostscript, as with a previous problem that Sean reported just before IM 6.4.0-3)