compare.exe generates bad comparison image with 32-bit TIFF

[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):

[magick]

Post a URL to your TIFF images so we can download them and reproduce the problem.

[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

[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)

[Drarakel]

@mmacvicar: It seems that test2.tiff is only 16bit per channel, not 32bit.(?)

[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

[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.

[mmacvicar]

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.

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?

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

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?

[fmw42]

I am very surprised you can deal with this 32/15-bit data without compiling in IM HDRI Q16 or Q32.