Image Orientation tag and rotating images

View: New views
10 Messages — Rating Filter:   Alert me  

Parent Message unknown Image Orientation tag and rotating images

by Richard Nolde :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Concerning rotating images in tiffcrop:
I've been working on the orientation tag issue for images rotated with
tiffcrop and I get two distinctly different results with a variety of
viewers.  Below are the outputs from tiffinfo on the original image and
three versions rotated by 90, 180, and 270 degrees clockwise. The test
document has three pages but I am only showing the results for the first
page in each case.

My first question is whether I have made the correct adjustments to the
orientation tag for rotations of 90, 180, and 270 degrees clockwise.  
Photoshop 7 on Winders displays the files as I would expect to see them,
which is the same as before I added the code to change the orientation
field in the output file.  The Gimp 2.4.5 on Win2K and Fedora 8 display
them as I would expect as well. The same is true for Qfaxreader.
However, DIMIN Viewer n5 and 11 View on Winders and GThumb 2.7.10 on
Fedora 8 seem to be adding an additional mirroring operation to the
displayed image, eg. rotating by 90 degrees clockwise puts the top of
the original image on the right of the new image, but now the left and
right sides of the original, albeit rotated image to top and bottom
positions, are reversed so that I am seeing the text from the back side
as though the top and bottom of the rotated image are now reversed.
GQView 2.0.4 and Mirage 0.9.3 on Fedora 8 display R180 the same as the
original and R270 the same as R90, both of which are rotated 90 and then
mirrored vertically. Quickscan 1.0 Level3 and Quickscan 4.0 by Captiva
Software on Winders display all the images in the original orientation.

My second question is whether I should be updating the orientation tag
in addition to transforming the data or is that the cause of the
problem.  Based on earlier posts to this list, it looks like an
either/or proposition but not both. I could offer the option to modify
the data or the tag or both as my current code does for inverting the
photometric interpretation tag for bilevel and grayscale images. My
concept is allow users to "fix" incorrectly stored images as well as to
modify the data when that is the desired result, but since this tag is
not always supported according to the TIFF 6.0 spec, I want the majority
of Linux viewers to be able to display the images correctly. It is only
since I added the new code to modify the orientation tag, that I have
seen the problem.  Previously, all images were written out with the
orientation tag copied from the input file even though the data are
being reoriented and for all the images I have, this was
ORIENTATION_TOPLEFT. If I rotate the image 90 degrees in Photoshop 7 on
Winders, the orientation tag is no longer reported by tiffinfo.
Quickscan Pro rotates the image data but does not update the orientation
tag.

tiffinfo /tmp/test.tiff
TIFF Directory at offset 0x2738 (10040)
  Subfile Type: multi-page document (2 = 0x2)
  Image Width: 2552 Image Length: 4200
  Resolution: 300, 300 pixels/inch
  Bits/Sample: 1
  Compression Scheme: CCITT Group 4
  Photometric Interpretation: min-is-white
  Thresholding: bilevel art scan
  FillOrder: lsb-to-msb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 4200
  Min Sample Value: 0
  Max Sample Value: 1
  Planar Configuration: single image plane
  Page Number: 0-3
  Make: RICOH
  Group 4 Options: (0 = 0x0)

tiffinfo /tmp/testR90.tiff
TIFF Directory at offset 0x30ce (12494)
  Subfile Type: multi-page document (2 = 0x2)
  Image Width: 4200 Image Length: 2552
  Resolution: 300, 300 pixels/inch
  Bits/Sample: 1
  Compression Scheme: CCITT Group 4
  Photometric Interpretation: min-is-white
  Thresholding: bilevel art scan
  FillOrder: lsb-to-msb
  Orientation: row 0 lhs, col 0 bottom
  Samples/Pixel: 1
  Rows/Strip: 2552
  Min Sample Value: 0
  Max Sample Value: 1
  Planar Configuration: single image plane
  Page Number: 0-3
  Make: RICOH
  Group 4 Options: (0 = 0x0)

tiffinfo /tmp/testR180.tiff
TIFF Directory at offset 0x270e (9998)
  Subfile Type: multi-page document (2 = 0x2)
  Image Width: 2552 Image Length: 4200
  Resolution: 300, 300 pixels/inch
  Bits/Sample: 1
  Compression Scheme: CCITT Group 4
  Photometric Interpretation: min-is-white
  Thresholding: bilevel art scan
  FillOrder: lsb-to-msb
  Orientation: row 0 bottom, col 0 rhs
  Samples/Pixel: 1
  Rows/Strip: 4200
  Min Sample Value: 0
  Max Sample Value: 1
  Planar Configuration: single image plane
  Page Number: 0-3
  Make: RICOH
  Group 4 Options: (0 = 0x0)


tiffinfo /tmp/testR270.tiff
TIFF Directory at offset 0x34b0 (13488)
  Subfile Type: multi-page document (2 = 0x2)
  Image Width: 4200 Image Length: 2552
  Resolution: 300, 300 pixels/inch
  Bits/Sample: 1
  Compression Scheme: CCITT Group 4
  Photometric Interpretation: min-is-white
  Thresholding: bilevel art scan
  FillOrder: lsb-to-msb
  Orientation: row 0 rhs, col 0 top
  Samples/Pixel: 1
  Rows/Strip: 2552
  Min Sample Value: 0
  Max Sample Value: 1
  Planar Configuration: single image plane
  Page Number: 0-3
  Make: RICOH
  Group 4 Options: (0 = 0x0)


Here is the piece of code that I am testing to assign the new
orientation value.  Rotation is the clockwise value being applied to the
image data itself and image->orientation is initially the value read
from the source image and it gets reset to the new value below before
being written back to the output file. If it turns out that I should not
update the orientation tag when reordering the image pixels, I can make
this code conditional based on the users request to update the tag OR to
update only the tag.

  switch (rotation)
    {
    case 90:
      switch (image->orientation)
        {
        case ORIENTATION_TOPLEFT:     /* 1, row 0 top, col 0 lhs */
             image->orientation += 2;
        case ORIENTATION_TOPRIGHT:    /* 2, row 0 top, col 0 rhs */
             image->orientation += 2;
        case ORIENTATION_BOTRIGHT:    /* 3, row 0 bottom, col 0 rhs */
             image->orientation += 2;
        case ORIENTATION_BOTLEFT:     /* 4, row 0 bottom, col 0 lhs */
             image->orientation += 1;
             break;
        case ORIENTATION_RIGHTTOP:    /* 6, row 0 rhs, col 0 top */
        case ORIENTATION_LEFTBOT:     /* 8, row 0 lhs, col 0 bottom */
             image->orientation -= 2;
        case ORIENTATION_LEFTTOP:     /* 5, row 0 lhs, col 0 top */
        case ORIENTATION_RIGHTBOT:    /* 7, row 0 rhs, col 0 bottom */
             image->orientation -= 3;
             break;
        default: image->orientation = ORIENTATION_TOPLEFT;
        }
      break;
    case 180:
      switch (image->orientation)
        {
        case ORIENTATION_TOPLEFT:     /* 1, row 0 top, col 0 lhs */
        case ORIENTATION_TOPRIGHT:    /* 2, row 0 top, col 0 rhs */
        case ORIENTATION_LEFTTOP:     /* 5, row 0 lhs, col 0 top */
        case ORIENTATION_RIGHTTOP:    /* 6, row 0 rhs, col 0 top */
             image->orientation += 2;
             break;
        case ORIENTATION_BOTRIGHT:    /* 3, row 0 bottom, col 0 rhs */
        case ORIENTATION_BOTLEFT:     /* 4, row 0 bottom, col 0 lhs */
        case ORIENTATION_RIGHTBOT:    /* 7, row 0 rhs, col 0 bottom */
        case ORIENTATION_LEFTBOT:     /* 8, row 0 lhs, col 0 bottom */
             image->orientation -= 2;
             break;
        default: image->orientation = ORIENTATION_TOPLEFT;
        }
      break;
    case 270:
      switch (image->orientation)
        {
        case ORIENTATION_TOPLEFT:     /* 1, row 0 top, col 0 lhs */
        case ORIENTATION_BOTRIGHT:    /* 3, row 0 bottom, col 0 rhs */
             image->orientation += 2;
        case ORIENTATION_TOPRIGHT:    /* 2, row 0 top, col 0 rhs */
        case ORIENTATION_BOTLEFT:     /* 4, row 0 bottom, col 0 lhs */
             image->orientation += 3;
             break;
        case ORIENTATION_LEFTBOT:     /* 8, row 0 lhs, col 0 bottom */
             image->orientation -= 2;
        case ORIENTATION_RIGHTBOT:    /* 7, row 0 rhs, col 0 bottom */
             image->orientation -= 2;
        case ORIENTATION_RIGHTTOP:    /* 6, row 0 rhs, col 0 top */
             image->orientation -= 2;
        case ORIENTATION_LEFTTOP:     /* 5, row 0 lhs, col 0 top */
             image->orientation -= 1;
             break;
        default: image->orientation = ORIENTATION_TOPLEFT;
    }
      break;
    default:  TIFFError("rotateImage", "Invalid rotation angle %d",
rotation);
              return (-1);
    }

Richard Nolde
Tiffcrop author

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Dr. Michael J. Chudobiak :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Richard Nolde wrote:
> My first question is whether I have made the correct adjustments to the
> orientation tag for rotations of 90, 180, and 270 degrees clockwise.  
> Photoshop 7 on Winders displays the files as I would expect to see them,
> which is the same as before I added the code to change the orientation
> field in the output file.  The Gimp 2.4.5 on Win2K and Fedora 8 display
> them as I would expect as well. The same is true for Qfaxreader.
> However, DIMIN Viewer n5 and 11 View on Winders and GThumb 2.7.10 on
> Fedora 8 seem to be adding an additional mirroring operation to the

Some comments:

1) libtiff support for orientation is a little odd, because libtiff
automatically adjusts for orientations 1-4 (which preserve the height
and width), but not 5-8 (which swap height and width). Beware! The
gdk-pixbuf loader compensates for this, in gtk 2.11.5 and later. Search
for "TIFFTAG_ORIENTATION" in
http://svn.gnome.org/viewvc/gtk%2B/trunk/gdk-pixbuf/io-tiff.c?revision=21115&view=markup 
to see what the gdk-pixbuf loader does.

2) If you have gtk 2.11.5 and gthumb 2.10.8 or later, gthumb should show
the oriented tiffs correctly. Older combinations of gtk/gthumb will not
be correct.


> My second question is whether I should be updating the orientation tag
> in addition to transforming the data or is that the cause of the
> problem.  Based on earlier posts to this list, it looks like an
> either/or proposition but not both. I could offer the option to modify
> the data or the tag or both as my current code does for inverting the

3) If you transform the data to reflect the orientation tag, the
orientation tag should be reset to "top left", or be removed entirely.

4) Orientation tag support for tiff is spotty, so the safest route is to
transform the data and remove the orientation tag.

- Mike
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Richard Nolde :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Dr. Michael J. Chudobiak wrote:

> Richard Nolde wrote:
>> My first question is whether I have made the correct adjustments to
>> the orientation tag for rotations of 90, 180, and 270 degrees
>> clockwise.  Photoshop 7 on Winders displays the files as I would
>> expect to see them, which is the same as before I added the code to
>> change the orientation field in the output file.  The Gimp 2.4.5 on
>> Win2K and Fedora 8 display them as I would expect as well. The same
>> is true for Qfaxreader. However, DIMIN Viewer n5 and 11 View on
>> Winders and GThumb 2.7.10 on Fedora 8 seem to be adding an additional
>> mirroring operation to the
>
> Some comments:
>
> 1) libtiff support for orientation is a little odd, because libtiff
> automatically adjusts for orientations 1-4 (which preserve the height
> and width), but not 5-8 (which swap height and width). Beware! The
> gdk-pixbuf loader compensates for this, in gtk 2.11.5 and later.
> Search for "TIFFTAG_ORIENTATION" in
> http://svn.gnome.org/viewvc/gtk%2B/trunk/gdk-pixbuf/io-tiff.c?revision=21115&view=markup 
> to see what the gdk-pixbuf loader does.
>
> 2) If you have gtk 2.11.5 and gthumb 2.10.8 or later, gthumb should
> show the oriented tiffs correctly. Older combinations of gtk/gthumb
> will not be correct.
>
My working system has versions of gtk+ and gthumb which are earlier than
those listed above which explains why I am not seeing the desired
results with those applications.

>
>> My second question is whether I should be updating the orientation
>> tag in addition to transforming the data or is that the cause of the
>> problem.  Based on earlier posts to this list, it looks like an
>> either/or proposition but not both. I could offer the option to
>> modify the data or the tag or both as my current code does for
>> inverting the
>
> 3) If you transform the data to reflect the orientation tag, the
> orientation tag should be reset to "top left", or be removed entirely.
>
> 4) Orientation tag support for tiff is spotty, so the safest route is
> to transform the data and remove the orientation tag.
>
> - Mike
>
This confirms my suspicions that modifying both the data and the tag is
incorrect, or at least will not produce the results I want.  It is
curious however, that QuickScan Pro, a commerical scanning program,
shows the original orientation when both are modified.  This suggests
that it is rotating the display data to conform to the value in the tag,
whereas the other applications are not doing this.

Thanks,
   Richard
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Bob Friesenhahn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tue, 30 Sep 2008, Richard Nolde wrote:

> Concerning rotating images in tiffcrop:
> I've been working on the orientation tag issue for images rotated with
> tiffcrop and I get two distinctly different results with a variety of
> viewers.  Below are the outputs from tiffinfo on the original image and three

It seems like hardly any software supports the orientation tag
correctly.  It seems that perhaps Photoshop does things correctly.

A problem with updating the orientation tag is that often it is wrong.
Perhaps the user wants to ignore the existing orientation flag, rotate
the image, and then set the orientation flag correctly.  Or perhaps
the user wants to turn the image right side up and remove the
orientation tag.

Ultimately, only the user knows for sure how to treat the orientation
tag since they can see the image

Bob
======================================
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Edward Lam :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Bob Friesenhahn wrote:
> It seems like hardly any software supports the orientation tag
> correctly.  It seems that perhaps Photoshop does things correctly.

This is very true. On the other hand, the TIFF6 spec states that only
the default value, 1 (ie. top-left), is required for baseline tiff
readers. Over here, we've completely given up on trying to output .tiff
files with non-default orientation values because of problems
encountered by our users when using them with other packages.

Ultimately, there should be at least two output choices: one for
baseline tiff files, and another for users who have tools that support
the non-baseline values of the orientation tag.

Cheers,
-Edward
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Richard Nolde :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Dr. Michael J. Chudobiak wrote:
> Richard Nolde wrote:
>> My first question is whether I have made the correct adjustments to
>> the orientation tag for rotations of 90, 180, and 270 degrees
>> clockwise. ...
> Some comments:
>
> 1) libtiff support for orientation is a little odd, because libtiff
> automatically adjusts for orientations 1-4 (which preserve the height
> and width), but not 5-8 (which swap height and width). Beware!
What file are you referring to when you say that libtiff automatically
adjusts for orientations 1- 4? I should have noted that I am using the
TIFFReadScanline and TIFFReadTile interfaces, not the TIFFReadRGBAImage
interface as found in tif_getimage.c. The current code to read and write
images is based on tiffcp.c which includes the following lines for
determining and then updating the orientation tag. This code suggests to
me that the issue is in the TIFFReadScanline and TIFFReadTile functions
which do not have any options to reverse the data in the input stream if
the orientation is right-handed as do TIFFReadRGBAImage related
functions in tif_getimage.c. It would not be hard to add this
functionality, but it isn't clear that it is going to solve anything for
the readers that don't handle the orientation tag properly.

  TIFFGetFieldDefaulted(in, TIFFTAG_ORIENTATION, &orientation);
  switch (orientation) {
    case ORIENTATION_BOTRIGHT:
    case ORIENTATION_RIGHTBOT:    /* XXX */
         TIFFWarning(TIFFFileName(in), "using bottom-left orientation");
         orientation = ORIENTATION_BOTLEFT;
         /* fall thru... */
    case ORIENTATION_LEFTBOT:    /* XXX */
    case ORIENTATION_BOTLEFT:
         break;
    case ORIENTATION_TOPRIGHT:
    case ORIENTATION_RIGHTTOP:    /* XXX */
    default:
         TIFFWarning(TIFFFileName(in), "using top-left orientation");
         orientation = ORIENTATION_TOPLEFT;
         /* fall thru... */
    case ORIENTATION_LEFTTOP:    /* XXX */
    case ORIENTATION_TOPLEFT:
         break;
   }

  TIFFSetField(out, TIFFTAG_ORIENTATION, orientation);

which I have replaced with

  TIFFSetField(out, TIFFTAG_ORIENTATION, image->orientation);

where image->orientation is set by the code previously noted based on
the original orientation and the desired rotation.
> 3) If you transform the data to reflect the orientation tag, the
> orientation tag should be reset to "top left", or be removed entirely.
However, in my case, I am not transforming the data to reflect the
orientation tag,  rather as a specific request to rotate the image by a
multiple of 90 degrees.  This leaves open the possibility that images
that did not have an orientation of TOPLEFT originally will still not
display properly in some applications since the code above does not
handle all orientations. It forces the orientation tag to a left-handed,
top or bottom, value.
> 4) Orientation tag support for tiff is spotty, so the safest route is
> to transform the data and remove the orientation tag.
> - Mike
One final question about what the proper behavior should be since this
is not a display application. Should the data be transformed to
ORIENTATION_TOPLEFT when an image with any other orientation is loaded
into memory under the assumption that this is the correct viewing
orientation?  Any requested rotations would then be made relative to the
adjusted viewing orientation rather than to the original orientation.  
Or should rotations be relative to the original image orientation
without regard to the proper viewing orientation. This is what I am
doing now.  In either case, it seems like resetting the orientation to
TOPLEFT is appropriate when the data are transformed.

Does anyone have images with orientations other than TOPLEFT that are
small enough to use for testing?
Richard
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Dr. Michael J. Chudobiak :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>> 1) libtiff support for orientation is a little odd, because libtiff
>> automatically adjusts for orientations 1-4 (which preserve the height
>> and width), but not 5-8 (which swap height and width). Beware!
> What file are you referring to when you say that libtiff automatically
> adjusts for orientations 1- 4? I should have noted that I am using the
> TIFFReadScanline and TIFFReadTile interfaces, not the TIFFReadRGBAImage
> interface as found in tif_getimage.c.

The above comments applied to TIFFReadRGBAImage, so you don't need to
worry about that. But it's still good to know...



>> 3) If you transform the data to reflect the orientation tag, the
>> orientation tag should be reset to "top left", or be removed entirely.
> However, in my case, I am not transforming the data to reflect the
> orientation tag,  rather as a specific request to rotate the image by a
> multiple of 90 degrees.  This leaves open the possibility that images
> that did not have an orientation of TOPLEFT originally will still not
> display properly in some applications since the code above does not
> handle all orientations. It forces the orientation tag to a left-handed,
> top or bottom, value.

In gthumb, we set it up so that you can rotate by:

1) changing the orientation tag only

or

2) by physically transforming the data and resetting the tag to top-left

In BOTH cases, we take into account the original orientation tag value.

We avoid physically transforming the data and having a non-top-left
output orientation tag. I guess you could do that if you wanted to, but
I wouldn't personally recommend it.

Officially, the EXIF standard does require you to reset the orientation
tag to top-left after a rotation.


> One final question about what the proper behavior should be since this
> is not a display application. Should the data be transformed to
> ORIENTATION_TOPLEFT when an image with any other orientation is loaded
> into memory under the assumption that this is the correct viewing
> orientation?  Any requested rotations would then be made relative to the
> adjusted viewing orientation rather than to the original orientation.  
> Or should rotations be relative to the original image orientation
> without regard to the proper viewing orientation. This is what I am
> doing now.  In either case, it seems like resetting the orientation to
> TOPLEFT is appropriate when the data are transformed.

In gthumb, we load the data, transform it based on the orientation tag,
and apply any requested operations (crop, rotate, whatever) based on the
transformed data. In other words, we always honor the orientation tag,
assuming that if the user didn't mean it, it wouldn't be in the file.

- Mike
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Richard Nolde :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Bob Friesenhahn wrote:

> On Tue, 30 Sep 2008, Richard Nolde wrote:
>
>> Concerning rotating images in tiffcrop:
>> I've been working on the orientation tag issue for images rotated
>> with tiffcrop and I get two distinctly different results with a
>> variety of viewers.  Below are the outputs from tiffinfo on the
>> original image and three
>
> It seems like hardly any software supports the orientation tag
> correctly.  It seems that perhaps Photoshop does things correctly.
The Captiva Software Quick Scan product was the only one I found that
showed the transformed images in the original orientation when the
orientation tag was modified at the same time as the data were
transformed. Photoshop 7, the only version I have, and the Gimp showed
it in the rotated position as though the orientation tag was TOPLEFT.

I've modified my code to read the orientation tag of the image and
perform any transforms needed to present the data in TOPLEFT orientation
(which I will call default viewing orientation) before any requested
transforms are applied.  In all cases, the orientation is set to TOPLEFT
after the transforms are applied, whether as a correction to the
incoming orientation or by explicit user request. This should provide a
valid display for applications that ignore the tag and those that handle
it properly since the final orientation is TOPLEFT in every case. This
should work for files with or without an orientation tag and it offers
the user the chance to force a transform just by specifying the
mirroring and/or rotations on the command line.  User specified
transforms will be applied after any orientation adjustments have been
applied so they are relative to the viewing orientation rather than the
original orientation.

Since my code works with 1,2,4,8, and 16 bit data, the only cases that I
suspect will be an issue are floating point images.  If anyone has a
small image with floating point data, I would be interested in seeing
what adjustments are needed.  Which viewers can be used to display TIFFs
with floating point data?

Richard

>
> A problem with updating the orientation tag is that often it is wrong.
> Perhaps the user wants to ignore the existing orientation flag, rotate
> the image, and then set the orientation flag correctly.  Or perhaps
> the user wants to turn the image right side up and remove the
> orientation tag.
>
> Ultimately, only the user knows for sure how to treat the orientation
> tag since they can see the image
>
> Bob
> ======================================
> Bob Friesenhahn
> bfriesen@...,
> http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>
>
>

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Bob Friesenhahn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, 1 Oct 2008, Richard Nolde wrote:
>
> Since my code works with 1,2,4,8, and 16 bit data, the only cases that I
> suspect will be an issue are floating point images.  If anyone has a small
> image with floating point data, I would be interested in seeing what
> adjustments are needed.  Which viewers can be used to display TIFFs with
> floating point data?

There is a floating point image included in the libtiff sample images.
GraphicsMagick is able to display it although it requires some manual
parameters to get the levels right (the file ranges between 0.0 and
720.0 or so) and does not pay any attention to rotation requests.

I did recently create a new collection of sample TIFF images,
including floating point ones, and put them out for ftp as
"ftp://ftp.graphicsmagick.org/pub/outgoing/tiff-sample-images.tar.bz2"
or
"ftp://ftp.graphicsmagick.org/pub/outgoing/tiff-sample-images.tar.gz".
These ones are little endian.

Bob
======================================
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: Image Orientation tag and rotating images

by Andrey Kiselev :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, Oct 01, 2008 at 10:32:22AM -0600, Richard Nolde wrote:
> >>My first question is whether I have made the correct adjustments to
> >>the orientation tag for rotations of 90, 180, and 270 degrees
> >>clockwise. ...
> >Some comments:
> >
> >1) libtiff support for orientation is a little odd, because libtiff
> >automatically adjusts for orientations 1-4 (which preserve the height
> >and width), but not 5-8 (which swap height and width). Beware!

> What file are you referring to when you say that libtiff automatically
> adjusts for orientations 1- 4?

Richard,

There is a TIFFReadRGBAImageOriented function which handles some of the
orientation stuff, but unfortunately it doesn't cover all the
possibilities. There was a bug filled in our old Bugzilla on the issue
(which is now lost) and it wasn't fixed because I haven't a good idea
how it should be done.

Best regards,
Andrey


--
Andrey V. Kiselev
ICQ# 26871517
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
LightInTheBox - Buy quality products at wholesale price!