16bit TIFF Files Seem To Be Broken

[RedSky]

Thank you Fred, but I'm just too paranoid to try that. I only have a marginal grasp of the Unix underpinnings of the Mac OS, and I'm not too swift with Macports either. I'm afraid I'll break something. I may only have to wait a day or two. If it takes too long I'll get back to ya.

Mike

[gnidam]

Version: ImageMagick 6.7.5-3 2012-02-07 Q16 / Arch Linux (64bit)
Features: OpenMP HDRI

Problem's gone, 16bit TIFFs come out fine again.
Thank you! Martin

[Drarakel]

I think that there's still an issue (though a small one).
The TIFF files itself have no problem anymore (no confusion with the ByteOrder). But IM doesn't interpret the FillOrder in a completely correct way.

Code: Select all

convert rose: -endian lsb rose.tif

It gets indeed written as LSB/FillOrder 'Reversed'/Little Endian (0x2). But when again read, IM thinks, it's called 'MSB':

Code: Select all

identify -verbose rose.tif

Endianess: MSB
And (correctly) writes it as MSB/FillOrder 'Normal' (with value 0x1) next time:

Code: Select all

convert rose.tif rose2.tif

But now thinks, it's 'LSB':

Code: Select all

identify -verbose rose2.tif

Endianess: LSB
After another round:

Code: Select all

convert rose2.tif rose3.tif
identify -verbose rose3.tif

Endianess: MSB
And so on.

The files are alright. But perhaps this alternation could be avoided?
The default FillOrder, according to the TIFF specs, should always be FillOrder 'Normal' (-endian 'msb' for ImageMagick).

[Drarakel]

By the way: "-define tiff:fill-order" (taken from here) doesn't seem to work at the moment? The fill order can only be changed with "-endian" (well, and with a simple read/write cycle, see above).

[magick]

We have 4 different key / value stores. We got the fill-order from the wrong key /value store. We will add a patch to fix the problem later today. Thanks.

[RedSky]

Version: ImageMagick 6.7.5-3 2012-02-10 Q32
Features: OpenMP OpenCL HDRI
Computer: MacBook Pro, OSX 10.6.8, 32bit Intel Processor

I finally got version 6.7.5-3 installed on my Mac via Macports. I tried the advanced installation described at:

http://www.imagemagick.com/www/advanced ... tml#macosx

but that just produced errors at the end of the "make" command and failed to install. Once I let the guys at Macports know there was an issue they provided the update within minutes.

16bit TIFF files are working again. Thanks for all your help!!

Mike

[Drarakel]

We have 4 different key / value stores. We got the fill-order from the wrong key /value store. We will add a patch to fix the problem later today. Thanks.

With v6.7.5-4, the fill order 'alternation' indeed disappeared. And the "tiff:fill-order" define now works, too.
Thank you!
(Another small problem with TIFF - on Windows systems - emerged now with the latest version. But I'll have to make a new thread for this..)

[jrrose]

I have a similar problem, if I try to write tiff files after performin a rotation with the original file. It happens if the original file is a png file or a tiff file.

rose@moose:/home/rose(405)$ convert -rotate 10 OrigImages/lena.png OutImages/lena.tiff
convert: tif_dirwrite.c:2084: TIFFWriteDirectoryTagCheckedRational: Assertion `value>=0.0' failed.
Abgebrochen
rose@moose:/home/rose(406)$ convert OrigImages/lena.png OutImages/lena.tiff
rose@moose:/home/rose(407)$ convert -version
Version: ImageMagick 6.7.5-3 2012-03-01 Q32 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
Features: OpenMP HDRI

rose@moose:/home/rose(408)$ convert OrigImages/lena.png OutImages/lena.tiff
rose@moose:/home/rose(410)$ convert -rotate 10 OrigImages/lena.png OutImages/lena_10deg_rotated.tiff
convert: tif_dirwrite.c:2084: TIFFWriteDirectoryTagCheckedRational: Assertion `value>=0.0' failed.
Abgebrochen

This is on Gentoo system, where I installed ImageMagick with:

root@moose:/usr/src(26)# emerge -pvD imagemagick
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] media-gfx/imagemagick-6.7.5.3-r1 USE="X bzip2 cxx djvu fftw fontconfig fpx graphviz gs hdri jbig jpeg jpeg2k lcms openexr openmp pango perl png q32 svg tiff truetype wmf xml zlib -autotrace -corefonts -lqr -lzma -opencl (-q64) -q8 -raw -static-libs -test -webp" 0 kB

On a Sabayon-8-LiveDVD with ImageMagick 6.7.4-0 I have the same problem:
sabayon ~ # convert -version
Version: ImageMagick 6.7.4-0 2011-12-30 Q16 http://www.imagemagick.org
...
Features: OpenMp

sabayon ~ # convert -rotate 10 rose: rose_ratated.tiff
convert: tif_dirwrite.c:2084: TIFFWriteDirectoryTagCheckedRational: Assertion `value>=0.0' failed.
Aborted.

On a aptosid system with ImageMagick 6.6.9-7 everything is fine:
identify -version
Version: ImageMagick 6.6.9-7 2012-02-22 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP

convert -rotate 10 OrigImages/lena.png OutImages/lena_10deg_rotated.tiff works

The same result I get with ImageMagick 6.6.0-4 on Ubuntu:

identify -version
Version: ImageMagick 6.6.0-4 2011-06-15 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP

convert -rotate 10 OrigImages/lena.png OutImages/lena_10deg_rotated.tiff works.

[fmw42]

If this is an endian problem as has been the case for a number of releases, then you need to upgrade as per the previous comment:

"With v6.7.5-4, the fill order 'alternation' indeed disappeared. And the "tiff:fill-order" define now works, too."

If it is something else, then you probably need to provide a link to your tiff file that does not work.

By the way, in IM 6, the correct syntax is now

convert image -rotate .... result

You read the image first and then operate on it.

see
http://www.imagemagick.org/Usage/basics/#cmdline