Page 1 of 1
compare.exe generates bad comparison image with 32-bit TIFF
Posted: 2010-06-18T17:01:44-07:00
by mmacvicar
compare.exe generates bad comparison image with 32-bit TIFF
This issue was reproduced with compare.exe v6.6.2-5
This functionality was working as recently as compare.exe v6.4
Reproducible Steps:
1. compare two floating point (32-bit) TIFF images that are different ("compare.exe test1.tiff test2.tiff output.tiff")
The resulting comparison will not be correct. Sometimes the resulting image is all read, other times it is almost completely white.
the resulting image should have the differences highlighted in red and the rest made closer to white.
test1.tiff:
test2.tiff:
compare_6.6.2-5_result.tiff (wrong):
compare_6.4.0_results.tiff (correct):
Re: compare.exe generates bad comparison image with 32-bit T
Posted: 2010-06-18T17:25:48-07:00
by magick
Post a URL to your TIFF images so we can download them and reproduce the problem.
Re: compare.exe generates bad comparison image with 32-bit T
Posted: 2010-06-21T09:51:28-07:00
by mmacvicar
Doh, I didn't realize tinypic converted them to jpg.
Attaching these to the forum would be easier, but here are some links to the images so that you can reproduce the issue.
test1.tiff
test2.tiff
Re: compare.exe generates bad comparison image with 32-bit T
Posted: 2010-06-21T10:57:35-07:00
by magick
ImageMagick is behaving correctly. These two images differ in areas other than the center cut-out. Here are the first few pixels from each image:
test1:
- # ImageMagick pixel enumeration: 64,64,65535,rgba
0,0: ( 512,65023, 0,65535) #0200FDFF0000 rgba(0.781262%,99.2187%,0%,1)
1,0: ( 1536,65023, 0,65535) #0600FDFF0000 rgba(2.34379%,99.2187%,0%,1)
2,0: ( 2560,65023, 0,65535) #0A00FDFF0000 rgba(3.90631%,99.2187%,0%,1)
3,0: ( 3584,65023, 0,65535) #0E00FDFF0000 rgba(5.46883%,99.2187%,0%,1)
4,0: ( 4608,65023, 0,65535) #1200FDFF0000 rgba(7.03136%,99.2187%,0%,1)
5,0: ( 5632,65023, 0,65535) #1600FDFF0000 rgba(8.59388%,99.2187%,0%,1)
6,0: ( 6656,65023, 0,65535) #1A00FDFF0000 rgba(10.1564%,99.2187%,0%,1)
7,0: ( 7680,65023, 0,65535) #1E00FDFF0000 rgba(11.7189%,99.2187%,0%,1)
8,0: ( 8704,65023, 0,65535) #2200FDFF0000 rgba(13.2815%,99.2187%,0%,1)
9,0: ( 9728,65023, 0,65535) #2600FDFF0000 rgba(14.844%,99.2187%,0%,1)
10,0: (10752,65023, 0,65535) #2A00FDFF0000 rgba(16.4065%,99.2187%,0%,1)
test2:
- # ImageMagick pixel enumeration: 64,64,65535,rgba
0,0: ( 8886,65535, 1789,65472) #22B6FFFF06FDFFC0 rgba(13.5592%,100%,2.72984%,0.999039)
1,0: ( 9096,65535, 1790,65472) #2388FFFF06FEFFC0 rgba(13.8796%,100%,2.73136%,0.999039)
2,0: ( 9303,65535, 1792,65472) #2457FFFF0700FFC0 rgba(14.1955%,100%,2.73442%,0.999039)
3,0: ( 9528,65535, 1793,65472) #2538FFFF0701FFC0 rgba(14.5388%,100%,2.73594%,0.999039)
4,0: ( 9798,65535, 1795,65472) #2646FFFF0703FFC0 rgba(14.9508%,100%,2.73899%,0.999039)
5,0: (10113,65535, 1797,65472) #2781FFFF0705FFC0 rgba(15.4314%,100%,2.74205%,0.999039)
6,0: (10470,65535, 1800,65472) #28E6FFFF0708FFC0 rgba(15.9762%,100%,2.74662%,0.999039)
7,0: (10869,65535, 1802,65472) #2A75FFFF070AFFC0 rgba(16.585%,100%,2.74968%,0.999039)
8,0: (11309,65535, 1806,65472) #2C2DFFFF070EFFC0 rgba(17.2564%,100%,2.75578%,0.999039)
9,0: (11787,65535, 1809,65472) #2E0BFFFF0711FFC0 rgba(17.9858%,100%,2.76036%,0.999039)
10,0: (12302,65535, 1813,65472) #300EFFFF0715FFC0 rgba(18.7716%,100%,2.76646%,0.999039)
Re: compare.exe generates bad comparison image with 32-bit T
Posted: 2010-06-21T12:14:21-07:00
by Drarakel
@mmacvicar: It seems that test2.tiff is only 16bit per channel, not 32bit.(?)
Re: compare.exe generates bad comparison image with 32-bit T
Posted: 2010-08-17T11:50:44-07:00
by mmacvicar
Apologies for taking so long to get back to this. For some reason I missed the responses to this thread.
And thank you for noticing my error. I've been having difficulty reproducing the bug I'm experiencing in a way that I could report to the imagemagick community.
Here are two actual 32bit floating point TIFFs and their comparisons using compare.exe 6.4.0 and 6.6.3-7 on Vista64. Compare.exe 6.4.0 creates an output image like I would expect with the differences in the images highlighted red, and the similarities highlighted in white. Compare.exe 6.6.3-7 makes the differences solid red, the similarities solid white, the top edge is colored red/blue, and the right edge is colored green/blue.
Original 32bit floating point tiff image:
http://www.4shared.com/photo/cqcgMrxu/normal.html
Original 32bit floating point tiff image with a hole in the center:
http://www.4shared.com/photo/Y9rIHvot/hole.html
Comparison results of normal.tiff and hole.tiff using compare 6.4.0. Output as a 16bit image:
http://www.4shared.com/photo/fUfODYpI/c ... s_640.html
Comparison results of normal.tiff and hole.tiff using compare 6.6.3.7. Output as a 32bit image:
http://www.4shared.com/photo/LrLHXeoh/c ... 663-7.html
Thanks,
Mark MacVicar
Re: compare.exe generates bad comparison image with 32-bit T
Posted: 2010-08-17T18:53:10-07:00
by fmw42
What Q level of IM are you using? I would think that if you have 32-bit TIFFs that you would need Q32 or HDRI IM compile (depending upon whether your files have negative values) to make a fair comparison.
Both your tiff files have supposedly fully transparent alpha channels per the verbose info but are not visually transparent. So this might be an IM bug. But when the alpha channels are removed, the files are quite different looking (not very smooth, but with stripes in both dimensions).
Also the range of values in your files have min of -infinity and max of very small values:
identify -verbose normal.tiff (run on Q16 HDRI)
...
Red:
min: -inf (-inf)
max: 2.48413e-32 (3.79054e-37)
mean: nan (nan)
standard deviation: nan (nan)
kurtosis: nan
skewness: nan
Green:
min: -inf (-inf)
max: 2.48413e-32 (3.79054e-37)
mean: nan (nan)
standard deviation: nan (nan)
kurtosis: nan
skewness: nan
Blue:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0
Alpha:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0
So I would think you need to be in IM Q32 HDRI to do any fair comparison. You may also need to invoke:
-depth 32 -define quantum:format=floating-point
see
http://www.imagemagick.org/Usage/formats/#tiff
But I am not really an expert on these issues. So perhaps one of the IM experts can comment further.
Re: compare.exe generates bad comparison image with 32-bit T
Posted: 2010-08-19T10:20:59-07:00
by mmacvicar
fmw42 wrote:What Q level of IM are you using? I would think that if you have 32-bit TIFFs that you would need Q32 or HDRI IM compile (depending upon whether your files have negative values) to make a fair comparison.
I am running ImageMagick-6.6.3-7-Q16-windows-x64-dll.exe. I was figuring that if it worked in 6.4 it would still work in 6.6.
fmw42 wrote:
Both your tiff files have supposedly fully transparent alpha channels per the verbose info but are not visually transparent. So this might be an IM bug. But when the alpha channels are removed, the files are quite different looking (not very smooth, but with stripes in both dimensions).
I've seen striping/banding when I convert the images to lower color depth. Is that what might have happened when you removed the alpha channel?
fmw42 wrote:
Also the range of values in your files have min of -infinity and max of very small values:
I get totally different results from yours when I run identify --verbose normal.tiff. My alpha is normal and my color mins are not -inf. I hope my file isn't being corrupted by the upload/download site. The only oddity that sticks out to me is the 15bit color depth.
Code: Select all
Image: normal.tiff
Format: TIFF (Tagged Image File Format)
Class: DirectClass
Geometry: 64x64+0+0
Resolution: 100x100
Print size: 0.64x0.64
Units: PixelsPerInch
Type: TrueColorMatte
Base type: TrueColor
Endianess: MSB
Colorspace: RGB
Depth: 32/15-bit
Channel depth:
red: 15-bit
green: 15-bit
blue: 1-bit
alpha: 1-bit
Channel statistics:
Red:
min: 512 (0.00781262)
max: 65023 (0.992187)
mean: 32767.5 (0.5)
standard deviation: 18915.9 (0.288638)
kurtosis: -1.20056
skewness: 7.15653e-014
Green:
min: 512 (0.00781262)
max: 65023 (0.992187)
mean: 32767.5 (0.5)
standard deviation: 18915.9 (0.288638)
kurtosis: -1.20056
skewness: 7.27196e-014
Blue:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: 0 (0)
kurtosis: 0
skewness: 0
Alpha:
min: 65535 (1)
max: 65535 (1)
mean: 65535 (1)
standard deviation: 0 (0)
kurtosis: 0
skewness: 0
Image statistics:
Overall:
min: 0 (0)
max: 65023 (0.992187)
mean: 16383.8 (0.25)
standard deviation: 13375.5 (0.204098)
kurtosis: 11.8524
skewness: 3.67471
Rendering intent: Undefined
Interlace: None
Background color: white
Border color: rgba(223,223,223,1)
Matte color: grey74
Transparent color: none
Compose: Over
Page geometry: 64x64+0+0
Dispose: Undefined
Iterations: 0
Compression: None
Orientation: TopLeft
Properties:
date:create: 2010-08-16T17:02:11-07:00
date:modify: 2010-08-16T16:48:05-07:00
signature: ad8c6c3290aa41775894c56061298282df2f924bc28d26a33d948b512a77780a
tiff:alpha: unassociated
tiff:endian: lsb
tiff:photometric: RGB
tiff:rows-per-strip: 8
Artifacts:
verbose: true
Tainted: False
Filesize: 65.8KB
Number pixels: 4.1K
Pixels per second: 4.09M
User time: 0.000u
Elapsed time: 0:01.001
Version: ImageMagick 6.6.3-7 2010-08-14 Q16 http://www.imagemagick.org
fmw42 wrote:
So I would think you need to be in IM Q32 HDRI to do any fair comparison. You may also need to invoke:
-depth 32 -define quantum:format=floating-point
see
http://www.imagemagick.org/Usage/formats/#tiff
But I am not really an expert on these issues. So perhaps one of the IM experts can comment further.
This helped "-define quantum:format=floating-point" did the trick. Everything is happy now thank you.
You also helped me discover that the original results I got with compare 6.6.3.7 display correctly using imdisplay, but not using HDRshop. Perhaps this is their bug?
Re: compare.exe generates bad comparison image with 32-bit T
Posted: 2010-08-19T11:53:41-07:00
by fmw42
I am very surprised you can deal with this 32/15-bit data without compiling in IM HDRI Q16 or Q32.