|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
|
|
|
|
|
Re: Image Orientation tag and rotating imagesRichard 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 imagesDr. 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. > 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 > 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 imagesOn 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 imagesBob 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 imagesDr. 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>> 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 imagesBob 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. 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 imagesOn 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 imagesOn 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/ |
| Free Forum Powered by Nabble | Forum Help |