Cropping CCITT G4 tif files.

2008-12-31
2013-03-27
  • Ed Williams
    Ed Williams
    2008-12-31

      If I try to crop a file from my scanner with "gm convert -crop NXxNY+OX+OY file.tif  croppedfile.tif"
    I get a file that is unreadable by xv (it shows errors in FaxDecode)
    whereas doing the identical thing with  convert  (ie ImageMagick) works.

    tiffinfo gives

    TIFF Directory at offset 0x12da
      Image Width: 750 Image Length: 750
      Resolution: 300, 300 pixels/inch
      Bits/Sample: 1
      Sample Format: unsigned integer
      Compression Scheme: CCITT Group 4
      Photometric Interpretation: min-is-white
      FillOrder: lsb-to-msb
      Document Name: "test48lapp1s10cgm.tif"
      Orientation: row 0 top, col 0 lhs
      Samples/Pixel: 1
      Rows/Strip: 750
      Planar Configuration: single image plane
      Page Number: 0-1
      Software: GraphicsMagick 1.3.3 2008-12-09 Q8 http://www.GraphicsMagick.org/

    for the gm-produced file and

    TIFF Directory at offset 0x12da
      Image Width: 750 Image Length: 750
      Resolution: 300, 300 pixels/inch
      Bits/Sample: 1
      Compression Scheme: CCITT Group 4
      Photometric Interpretation: min-is-white
      FillOrder: msb-to-lsb
      Document Name: "test48lapp1s10c.tif"
      Orientation: row 0 top, col 0 lhs
      Samples/Pixel: 1
      Rows/Strip: 750
      Planar Configuration: single image plane
      Software: ImageMagick 6.1.8 12/21/08 Q16 http://www.imagemagick.org

      I'm not sure the fillorder is significant for a 1bit/sample file - but it differs.

     
    • Is GraphicsMagick able to successfully read the file that it wrote?  If it can, then the file is not technically broken.

      Fill order specifies the endian-ordering of bytes at the bit level. Almost all modern computers use msb2lsb order.  GraphicsMagick uses reversed fill order for Group4 since RFC 2301 says to do so.  ImageMagick used to confuse endian with fill order. Regardless, libtiff is supposed to take care of this issue so if the bytes are reversed from the native order, there should only be a small loss of performance.  If you want to produce the same fill order as ImageMagick, then you can use

        -define tiff:fill-order=msb2lsb

      prior to the output file name.

      Here is the complete documentation for this define:

                     tiff:fill-order={msb2lsb|lsb2msb}

                          If the tiff:fill-order key is  defined,  Gra-
                          phicsMagick  will use it to determine the bit
                          fill order used while writing TIFF files. The
                          normal  default  is  "msb2lsb", which matches
                          the native bit order of all modern CPUs.  The
                          only  exception  to  this  is  when Group3 or
                          Group4 FAX compression is requested since FAX
                          machines  send data in bit-reversed order and
                          therefore RFC 2301 recommends  using  reverse
                          order.

       
    • Another difference I notice in the tiffinfo output is that the one for GraphicsMagick includes these extra lines:

      Sample Format: unsigned integer
      Page Number: 0-1

      Regardless, 'xv' is able to read the Group4 compressed TIFF written by GraphicsMagick on my system.

      Bob

       
      • Ed Williams
        Ed Williams
        2008-12-31

          Using the -define tiff:fill-order=msb2lsb  option worked for me, creating files that were readable both by xv and the application I actually cared about.

          It seems my xv can't handle lsb-msb ordering.

          Thanks for the quick response!

         
        • Xv dates from 1992 and comes with its own copy of libtiff.  It is a wonder that it works at all after all this time. Regardless, I still love it and build it from source code, plus public domain patches.