Not complient with TIFF standard

[robert_a]

with quoteDifferent behaviour between installation versions
HI,
I have a command that was working to give the correct ressult, I have compiled the current version of ImageMagick and now it gives a wrong result.
The command converts a 32-bit floating point TIFF in which the values lie in the range 0-65535 into a 16-bit TIFF in which the values are the truncated integers. I need to use a self-compiled Q32 installation for this purpose.
The 'wrong result' looks like it's quantized to only 8 grayscale "colours" and randomly assigned values, the 'right result' has integers equal to the floating-point values but truncated.
Any help, what has changed?



Here is the command:

Code: Select all

convert -define quantum:format=floating-point projections/p_00000.tif -evaluate divide 65536.0 -define quantum:format=integer -depth 16 image_6897.tif

Old version of ImageMagick covert that gives the result I want:

Code: Select all

$ convert -version
Version: ImageMagick 6.7.5-10 2012-03-05 Q32 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
Features: OpenMP HDRI

New version of ImageMagick convert that gives a different result -- looks like it is quantized to 8 bit then wrapped around the negative values??

Code: Select all

convert -version
Version: ImageMagick 6.8.9-7 Q32 x86_64 2014-09-15 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC HDRI OpenMP
Delegates: bzlib fftw fontconfig freetype jng jpeg lcms pangocairo png tiff x xml zlib

I have had some discussion with Snibgo in Developer forum, and he has demonstrated to my satisfactino that the calcuations of the ImageMagick command are correct, and reading back the output files via

Code: Select all

compare -metric RMSE image_from_version_6.8.9.7.tif image_from_version_6.7.5.10.tif NULL

claims the stored values are identical.
However the files are in fact different and display differently in ImageJ

Code: Select all

$ diff image_from_version_6.7.5.10.tif image_from_version_6.8.9.7.tif
Binary files image_from_version_6.7.5.10.tif and image_from_version_6.8.9.7.tif differ

The files are temporarily on anonymous ftp:
ftp://ftpanon.diamond.ac.uk/I12JEEP/ForImageMagick/
The file names : ' input_image.tif ' , the input image , 32-bit IEEE float TIFF file
'image_from_version_####.tif' -- the output image when the command is run with the specified version (compiled here)

The file
image_from_version_6.7.5.10.tif
contains the image I require.

The file
image_from_version_6.8.9.7.tif
contains the peculiar result with only 8 different values distributed among the 65536 possible values in a way that is not obvious to me.

Why , and in what way, are 16-bit grayscale TIFF files different between 6.7.5-10 and 6.8.9-7 ??

Thanks!

[robert_a]

The new version has 'fill order' set to '2' whereas the old version has 'fill order' set to '1'
'Fill order 2' is not supported universally and is not required to be supported by baseline TIFF standard. As my command did not specify any special fill order, there are two possible expected behaviours
-- use the order that was in the input file
-- use 'Fill order 1' as expected for the default
using 'fill order 2' when not specified and when the input is 'fill order 1' is wrong, this version of ImageMagick does not comply with the TIFF specifications.




posting.php?mode=quote&f=3&p=80719

The default FillOrder, according to the TIFF specs, should always be FillOrder 'Normal' (-endian 'msb' for ImageMagick).

TIFF Tag FillOrder
IFD Image
Code 266 (hex 0x010A)
Name FillOrder
LibTiff name TIFFTAG_FILLORDER
Type SHORT
Count 1
Default 1 (lower column values in higher order bits)
Description

The logical order of bits within a byte.

The specification defines these values:

1 = pixels with lower column values are stored in the higher-order bits of the byte.
2 = pixels with lower column values are stored in the lower-order bits of the byte.

The specification goes on to warn that FillOrder=2 should not be used in some cases to avoid ambigouty, and that support for FillOrder=2 is not required in Baseline TIFF compliant readers.

LibTiff defines these values:

FILLORDER_MSB2LSB = 1;
FILLORDER_LSB2MSB = 2;

In practice, the use of FillOrder=2 is very uncommon, and is not recommended.

[dlemstra]

Why have applied a patch that will use FILLORDER_MSB2LSB unless specified otherwise with the 'tiff:fill-order' setting. Thank you for reporting this. The fix will be available in ImageMagick 6.8.9-8.

[robert_a]

Thanks very much , I look forward to trying that soon.

I also can't quite understand the behaviour of the 'endian' flag, after figuring out that it's the fill-order that is causing trouble I found that if I inculde jsut the
+endian
flag, it saves in order '1' instead of '2', however this flag is specified to 'revert to unspecified' , yet in my command I did not specify . I woudl have thought that +endian woudl have no effect if -endian had not been specified somewhere.

-endian type
Specify endianness (MSB or LSB) of the image.

To print a complete list of endian types, use the -list endian option.

Use +endian to revert to unspecified endianness.

Also, maybe this is flogging a dead horse because I don't know the background, but it seems confusing to use 'endian style' to refer to both byte-order and bit-order without clarifying this, at least in the documentation if the flag names are too entrenched to change. AFAICT, the above mentioned flag alters the bit fill order , but the byte order of the stored data is not changed -- but the web page above just says 'endianness of the image'.