Byte Order Problem

[markzman]

It seems that ImageMagick-6.7.5-Q16 could not identify the byte order of TIF files properly.
endianess result is always LSB even on MAC byte order tif files.

Code: Select all

Image: MAC_sample.tif
  Format: TIFF (Tagged Image File Format)
  Class: DirectClass
  Geometry: 2023x1414+0+0
  Resolution: 300x300
  Print size: 6.74333x4.71333
  Units: PixelsPerInch
  Type: TrueColorMatte
  Base type: TrueColor
  Endianess: LSB
  Colorspace: RGB
  Depth: 8-bit
  Channel depth:
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 1-bit
  Channel statistics:
    Red:
      min: 0 (0)
      max: 255 (1)
      mean: 145.154 (0.56923)
      standard deviation: 114.361 (0.448476)
      kurtosis: -1.87993
      skewness: -0.151097
    Green:
      min: 0 (0)
      max: 255 (1)
      mean: 146.043 (0.572717)
      standard deviation: 114.056 (0.447279)
      kurtosis: -1.86376
      skewness: -0.171179
    Blue:
      min: 0 (0)
      max: 255 (1)
      mean: 140.677 (0.551676)
      standard deviation: 118.585 (0.46504)
      kurtosis: -1.90692
      skewness: -0.131617
    Alpha:
      min: 0 (0)
      max: 0 (0)
      mean: 0 (0)
      standard deviation: -1.#IND (-1.#IND)
      kurtosis: -1.#IND
      skewness: -1.#IND
  Image statistics:
    Overall:
      min: 0 (0)
      max: 255 (1)
      mean: 171.718 (0.673406)
      standard deviation: 100.187 (0.392891)
      kurtosis: -0.728352
      skewness: -0.880369
  Alpha: rgba(255,255,255,0)   #FFFFFF00
  Rendering intent: Undefined
  Interlace: None
  Background color: white
  Border color: rgba(223,223,223,1)
  Matte color: grey74
  Transparent color: none
  Compose: Over
  Page geometry: 2023x1414+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: LZW
  Orientation: TopLeft

[Drarakel]

I am understanding it that way that IM always showed the FillOrder (the order of the bits within one byte) with "Endianess". So, it tries to show the effect of "-endian" at the moment. The byte order is controlled with "-define tiff:endian" and is not shown with identify afterwards. Or was there a version that showed both in a correct way? (In some older version, I think, "-endian" changed both - the fill order AND the byte order - but identify showed only the fill order even then.)
But I support such a feature request - perhaps identify could output the fill order and the byte order.

[markzman]

Now I remember this used to work on ImageMagick-6.6.3-Q16 but the current release no longer supports this.
PC
tiff:endian: lsb
MAC
tiff:endian: msb

Can we have a patch for this?

[Drarakel]

You're right. With v6.7.3-6, this was still possible:

Code: Select all

convert -define tiff:endian=msb rose: -endian lsb tif:- | identify -verbose tif:-

Endianess: LSB
...
tiff:endian: msb

It seems that the output of "tiff:endian" stopped with v6.7.3-7.

[magick]

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

[anthony]

Okay let me just get this straight, for clarity.

How accurate is this summery, for IM Examples. And if not in what way is it wrong?

Code: Select all

    The order in which TIFF data values are stored is controled by
       -endian                   Global order of the bytes
       -define tiff:endian       Tiff format specific byte order
       -define tiff:fill-order   Bit order within a byte

    Each takes a value of either MSB (default) or LSB, however
    the "tiff:fill-order" will be set to the value of "tiff:endian"
    if that is defined, but not from the global endian value.

[Drarakel]

"-define tiff:endian" (byte order) is correct. But "-define tiff:fill-order" doesn't change anything (at least not for me). "-endian" sets the fill order right now. And there's no global setting or 'overlap'.
But both settings can be changed, so there's no problem with that (apart from a small confusion with the fill order which will be gone with the next version according to magick).

However, the problem in this thread was not a false setting, but the disappearance of "tiff:endian" in the identify output.

[anthony]

Strange the tiff coder references the define "tiff:fill-order"

In fact here are all the defines it does know about (extract from source)
"tiff:endian" "tiff:fill-order" "tiff:alpha" "tiff:rows-per-strip"

On top of this it also uses many per-image properties (-set), most of which are saved when a TIFF image was read in.
"tiff:photometric" "tiff:hostcomputer" "tiff:artist" "tiff:timestamp" "tiff:make" "tiff:model" "tiff:software" "tiff:copyright"
"kodak-33423" "kodak-36867" "label" "comment" "jpeg:sampling-factor"

And a few per-image "Options" (which I am less sure about)
"tiff:exif-properties" "tiff:tile-geometry"

A few more properties are just 'set' on read, but not used on write.
"tiff:document" "tiff:image-id"

What any of these actually mean I have not checked via the source, but I have listed some in IM examples, as I have seen them in the forums. I myself do nto use TIFF as I am not a windows user, and find the format to 'free-form' with far too many programs restricting themselves to very specific sub-types and usage. I tend to avoid it
http://www.imagemagick.org/Usage/formats/#tiff

[magick]

Try ImageMagick-6.7.5-4 and let us know if you continue to have problems with tiff:fill-order.

[Drarakel]

Try ImageMagick-6.7.5-4 and let us know if you continue to have problems with tiff:fill-order.

Works now. Thanks again.

"-define tiff:fill-order" does now the same as "-endian" (for TIFF). And the define takes precedence over "-endian", if both options are specified.
Another small difference to the summary in IM Examples:
The default fill order is (still) MSB - but the default for the byte order (tiff:endian) is LSB. If the input file is already TIFF, the fill order from this file is re-used for the output TIFF file. But the byte order is always reset to LSB (unless explicitly set with the tiff:endian define).

By the way - this seems to be outdated, too @Anthony:
http://www.imagemagick.org/Usage/formats/#tiff

Code: Select all

TIFF and EXIF profiles

    Cristy reported: The libtiff delegate library supports the EXIF profile
    but it was unreliable and caused faults too often so we commented out the
    call.

    To get the EXIF attributes try this.

      identify -verbose -define tiff:exif=true image.tif

The listing of the EXIF tags is now enabled per default. And there's no "tiff:exif" anymore, I think - as it's now "tiff:exif-properties".

[Drarakel]

However, most of the above is off-topic.
The problem of the OP was, that "tiff:endian" (the TIFF byte order) can't get output anymore:

With v6.7.3-6, this was still possible:

Code: Select all

convert -define tiff:endian=msb rose: -endian lsb tif:- | identify -verbose tif:-

Endianess: LSB
...
tiff:endian: msb

It seems that the output of "tiff:endian" stopped with v6.7.3-7.

@magick: Is it possible to have this back?

[magick]

ImageMagick support two endian options. The -endian command line option sets the fill order of the image pixels.. The -define tiff:fill-order does as well. The tiff:endian property set the image container byte order (its sets the open mode to either "wl" or "wb"). Given the above, how is ImageMagick not behaving properly?

[Drarakel]

The thread was not about false settings. (The chatter in between was there as Anthony asked about the current TIFF behaviour - for a new IM Examples summary, I presume.)

The OP asked whether it's possible that "identify -verbose" shows the byte order of a TIFF file.
Up to version 6.7.3-6, the byte order was shown as "tiff:endian" artifact. And that doesn't work anymore.

[fmw42]

seems to be working now in IM 6.7.5.6 Q16 Mac OSX Snow Leopard

convert rose: rose.tiff
identify -verbose rose.tiff
tiff:endian: lsb

[Drarakel]

So, it was added a few hours ago?
I can't test it, as there is no 6.7.5.6 Windows binary at the moment, I think. I'll wait.
Thanks!