Posted by
Carnë Draug on
Nov 04, 2014; 7:33pm
URL: http://imagej.273.s1.nabble.com/Fwd-ImageJ-reads-reversed-bits-from-unsigned-16-bit-TIFF-saved-by-imwrite-from-GNU-Octave-tp5010293p5010299.html
On 4 November 2014 17:57, Pariksheet Nanda <
[hidden email]> wrote:
> Hi Carnë,
>
> On Tue, Nov 4, 2014 at 10:42 AM, Carnë Draug <
[hidden email]> wrote:
>> On 3 November 2014 11:05, Pariksheet Nanda <
[hidden email]> wrote:
>>> Hi all,
>>>
>>> ImageJ shows pixel values different from those saved by GNU Octave.
>>> The byte positions are the same, the bits within each byte are
>>> reversed
>>>
>>> [...]
>>>
>>> 2) Can you help me identify where the problem might be coming from?
>>> GNU Octave has a wrapper for ImageMagick C++ interface, which in turn
>>> uses libtiff. Perhaps the next logical thing would be to inspect the
>>> binary values from the TIFF file or check the TIFF file headers, etc
>>> but I'm not sure how to approach those investigations. My application
>>> and library versions are:
>>>
>>> - ImageJ 1.49i (bundled with FIJI linux-32)
>>> - Octave 3.8.2
>>> - ImageMagick 6.8.8.10
>>> - libtiff 4.0.3
>>
>> I can't replicate this using Octave 3.8.2 on Debian Jessie with
>> GraphicsMagick 1.3.20 (quantum 16) and libtiff 4.0.3.
>
> I think you might have missed Michael's and Curtis' resposes in this
> thread. As Curtis suggested, the cause of the bit reversal was due to
> FillOrder TIFF tag being set to <2> i.e. reverse order:
>
http://imagej.1557.x6.nabble.com/ImageJ-reads-reversed-bits-from-unsigned-16-bit-TIFF-saved-by-imwrite-from-GNU-Octave-tp5010285p5010291.html> You can check for the FillOrder tag in the Multi-TIFF files with
> `tiffdump'. In all likelihood your GraphicsMagick setup either does
> not create this tag and thus per the Adobe TIFF6 specification it
> defaults to a value of <1> for normal FillOrder.
I see the now on nabble. I'm only subscribed to the daily digest and will
only get their emails tomorrow morning.
> 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.
Octave itself does not touch that option (there's not even a method to
set it from GraphicsMagick's C++ interface *) so you won't be able to specify
this from Octave. 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.
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).
Carnë
[7]
http://www.libtiff.org/build.html* there seems to be an undocumented way to do this. Looking at the source of
ImageMagick tiff coder there's an atribute with this value (this will return
nothing on GraphicsMagick and I do not know the ImageMagick version where it
was added). If the following works when reading a file, it may work to set
the attribute before writing.
#include <Magick++.h>
#include <iostream>
int
main (int argc, char **argv)
{
if (argc < 2)
return 1;
Magick::InitializeMagick (*argv);
Magick::Image image (argv[1]);
std::cout << image.attribute ("tiff:fill-order") << std::endl;
return 0;
}
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html