2004.05.15 19:00 "[Tiff] TIFFWriteScanline endian swapping issue", by Robert Seidl

2004.05.15 19:00 "[Tiff] TIFFWriteScanline endian swapping issue", by Robert Seidl

Using libtiff 3.6.1 on Intel, Win XP

I use TIFF writer code shown in several examples:

TIFFSetField(tif,TIFFTAG_IMAGEWIDTH,    (uint32)src.Size().fX );
TIFFSetField(tif,TIFFTAG_IMAGELENGTH,   (uint32)src.Size().fY );
uint16 channels = (it==TImage::eGray) ? 1 : (it==TImage::eRGB) ? 3 : 4;
TIFFSetField(tif,TIFFTAG_SAMPLESPERPIXEL, (uint16)channels );
TIFFSetField(tif,TIFFTAG_SAMPLEFORMAT,  1 ); // uint
int16  photometric = (it==TImage::eGray) ? PHOTOMETRIC_MINISBLACK :PHOTOMETRIC_RGB;
TIFFSetField(tif,TIFFTAG_PHOTOMETRIC,   photometric );
TIFFSetField(tif,TIFFTAG_PLANARCONFIG,  PLANARCONFIG_CONTIG); // "chunky" (not planar)

uint32 row;
for( row=0; row<src.Size().fY; row++) {
         // fill buffer from our TImage data
         if (!TIFFWriteScanline(tif, tdata_t(src.PixelPtr(row)), row))
         TIFFError("WriteImage","failure in WriteScanline\n");

When I write my RGB or RGBA images this way, it looks like the bytes are written in such an order that other programs on my PC (like Photoshop, CompuPic) display the "wrong" (eg byte flipped) images.

I have seen this bug report that I believe refers to the issue http://bugzilla.remotesensing.org/show_bug.cgi?id=437 but states that the fix went into 3.6.0 (I am using 3.6.1)

Also tried using "l" and "b" (little and big endian) parameters to the open call (re "Byte Order" paragraph on http://www.libtiff.org/man/TIFFOpen.3t.html )




but that did not change the output (which itself is a little puzzling). I should mention that I open the TIFF file through libgeotiff v.1.2.2 (1220) but I don't think thats the cause of my problem.

It could be that the readers somehow are not fully compliant - but I would suspect Photoshop could read TIFFs just fine, thus my suspicion about the TIFF writing code.

Any advice would be appreciated, thanks in advance

Robert Seidl