Legacy ImageMagick Discussions Archive

You put up two sample images on the ftp site, saying one was good and the other bad. But they seem to be identical:

They are not identical.

Because you are using ImageMagick to compare the values that ImageMagick reads in the images, you are getting the same values. So I am willing to beleive that your explanations and tests prove that there are no problems with the CALCULATIONS that ImageMagick is doing, and as we have settlled back on my original version of the required calculations, you have shown me that my original ImageMagick command is also correct. Thank you very much for that!


I suspect then that there is a problem with the STORAGE of the values into TIFF format, your test indicates that ImageMagick is doing something wierd for storing the values, which is at least consistent within IMageMagick since it reads back the same values, but that is not the same as what it has done in previous versions and is not compatible with other software that uses TIFF.

why are we talking about 8bit values?

snibgo wrote:from32f_out.tiff:
https://dl-web.dropbox.com/get/from32f_ ... SvULA&dl=1

I can't (don't know how?) to access this file. I have logged into drobpox and I still get "no permission, you have to log in" message

Sorry. Try: http://snibgo.com/imforums/from32f_out.tiff

"diff" will compare files, so internal metadata (creation dates etc) will cause the files to be different, even if the image data is identical.

I have no software, other than IM, that reads or writes 32-bit floating-point TIFF files. I can't confirm (or deny) that IM is reading/writing these files correctly, or is consistent between versions.

There doesn't seem to be date-specific data causing diff's because the same command shows no diff between the prior result of mine and the result of the command as you suggested without the leading define-quantum-floating business, executed on a different day.
I have started deeper investigation of my own into the tags. I am sure it has something to do with 'endian'

You could download Imagej for free

The files are different sizes. Therefore they are different, whether or not the images are different.

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

Drarakel wrote: 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.

If following this thread: see resolution in 'bugs' folder :

viewtopic.php?f=3&t=26262

dlemstra wrote: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.