Posted by
Pariksheet Nanda on
Nov 05, 2014; 7:32pm
URL: http://imagej.273.s1.nabble.com/Fwd-ImageJ-reads-reversed-bits-from-unsigned-16-bit-TIFF-saved-by-imwrite-from-GNU-Octave-tp5010293p5010321.html
Hi Carnë,
On Tue, Nov 4, 2014 at 7:33 PM, Carnë Draug <
[hidden email]> wrote:
>
> On 4 November 2014 17:57, Pariksheet Nanda <
[hidden email]> wrote:
>>
>> Since ImageJ2 handles Fill Order in reading the image, I'll ask the
>> Octave folks if they intended to use the esoteric Fill Order type <2>.
>
> According to libtiff documentation, you can specify FILLORDER when building
> libtiff [7]. Octave itself relies on GraphicsMagick (or ImageMagick) to make
> the right choice and they rely on libtiff.
>
> [...]
>
> But if I understood correctly, libtiff is acting correctly
> and saving the file as configured, it's ImageJ1 that is ignoring this tag
> and reading the file wrong, and this is already fixed if you are using SCIFIO.
>
> You should be able to fix this by rebuilding libtiff with different flags.
To get the same results as you, I had to install GraphicsMagick 1.3.18
and recompile Octave 3.8.2 configuring it -with-magick=GraphicsMagick
Unlike ImageMagick, GraphicsMagick does not invert the bits or write a
FillOrder tag.
libtiff no longer supports a configure argument changing FILLORDER
since it has been replaced by HOST_FILLORDER [8] and neither does the
Debian package for libtiff 4.0.3, you are using, patch [9] or modify
the variable [10]. The libtiff build page [7] is quite out of date
(last updated in 2003 in the page footer), and probably explains why
FillOrder is not user configurable.
Since there's little further relevance to ImageJ at this point, I'll
consider this thread closed. Thanks for everyone's help in narrowing
this down.
> Searching online, some people seem to also had success by running ImageMagick
> convert tool on the generated image (which would imply a system() on your
> code after writing the image).
I had tried `convert' and `mogrify' utilities, and besides needing
scripting to work with multi-TIFF, they are too smart for their own
good: for example `covert' changed several other TIFF tags like bit
depth.
> Carnë
Pariksheet
[8] There is HOST_FILLORDER, in ./configure.ac which just uses the
operating system endianness and there is also a definition for
HOST_BIGENDIAN.
[9]
http://sources.debian.net/src/tiff/4.0.3-10/debian/patches/[10]
http://sources.debian.net/src/tiff/4.0.3-10/debian/rules/--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html