2005.03.22 21:12 "[Tiff] wrong orientation using TIFFReadRGBAStrip", by Massimiliano Mazzeschi

2005.03.23 01:15 "Re: [Tiff] wrong orientation using TIFFReadRGBAStrip", by Ron

I'm trying to use TIFFReadRGBAStrip to read tif images, but I've got images with the wrong orientation.

You are not alone in that, xzgv and nautilus get this wrong too, at least.

my call stack is:

The function setorientation (tif_getimage.c) is called to understand which kind of flip needs to obtain a ''standard'' BOTLEFT image from any oriented image. My image is RIGHTTOP, and the function returns FLIP_HORIZONTALLY | FLIP_VERTICALLY, but is wrong! I suppose it should rotate and flip to do the right thing.

I can't say for sure how this is _supposed_ to work, but indeed, without the ability to rotate, it is impossible for this function to perform any arbitrary reorientation.

However it currently performs the re-orientations that it can do very efficiently, and we probably can't rotate with a similar algorithm, bits are going to have to be copied to do that, so...

What it does appear terribly useful for, is if you set:

tiff.req_orientation = tiff.orientation;

before you do your TIFFRGBAImageGet, then it will give you a raster in the (probably) more familiar top down form, with the actual orientation of the image in the raster being that which is specified by the orientation tag.

IOW. If you have an image with ORIENTATION_LEFTBOT, and do the above, you'll get a top down raster with the image shown 'sideways'. If you want it in some other orientation, you may have to rotate it yourself after that. If your image has TOPLEFT on the other hand, you will get a top down raster with the image appearing as you'd expect.

If you try to do anything else with this (such as set a req_orientation other than what is in the image or not set it at all), you will likely end up with a raster in which your image is oriented wrongly, flipped, or both. The apps mentioned do this to images out of my stills camera, doing the above in my own code seems to cause no such trouble and gives me top down rasters without copying the bits myself like many people seem to prefer -- or implementing my own putContig (and reimplemting all the decoding libtiff already does).

Someone might be able to give you a more formal description, but that's what I blackboxed from it so far. I haven't been looking at this code for long, but hth just the same.