Home/ Questions/Q 100299
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T00:33:11+00:00

I’m trying to read a 16-bit greyscale TIFF file (BitsPerSample=16) using a small C

  • 0

I’m trying to read a 16-bit greyscale TIFF file (BitsPerSample=16) using a small C program to convert into an array of floating point numbers for further analysis. The pixel data are, according to the header information, in a single strip of 2048×2048 pixels. Encoding is little-endian.
With that header information, I was expecting to be able to read a single block of 2048x2048x2 bytes and interpret it as 2048×2048 2-byte integers. What I in fact get is a picture split into four quadrants of 1024×1024 pixels each, the lower two of which contain only zeros. Each of the top two quadrants look like I expected the whole picture to look: alt text http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457.png
If I read the same file into Gimp or Imagemagick, both tell me that they have to reduce to 8-bit (which doesn’t help me – I need the full range), but the pixels turn up in the right places: alt text http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457_gimp.png This would suggest that my idea about how the data are arranged within the one strip is wrong. On the other hand, the file must be correctly formatted in terms of the header information as otherwise Gimp wouldn’t get it right. Where am I going wrong?

Output from tiffdump:
15_inRT_0p457.tiff:
Magic: 0x4949 Version: 0x2a
Directory 0: offset 8 (0x8) next 0 (0)
ImageWidth (256) LONG (4) 1<2048>
ImageLength (257) LONG (4) 1<2048>
BitsPerSample (258) SHORT (3) 1<16>
Compression (259) SHORT (3) 1<1>
Photometric (262) SHORT (3) 1<1>
StripOffsets (273) LONG (4) 1<4096>
Orientation (274) SHORT (3) 1<1>
RowsPerStrip (278) LONG (4) 1<2048>
StripByteCounts (279) LONG (4) 1<8388608>
XResolution (282) RATIONAL (5) 1<126.582>
YResolution (283) RATIONAL (5) 1<126.582>
ResolutionUnit (296) SHORT (3) 1<3>
34710 (0x8796) LONG (4) 1<0>
(Tag 34710 is camera information; to make sure this doesn’t somehow make any difference, I’ve zeroed the whole range from the end of the image file directory to the start of data at 0x1000, and that in fact doesn’t make any difference.)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. I’ve found the problem – it was in my C program…

    I had allocated memory for an array of longs and used fread() to read in the data:

    #define PPR 2048; #define BPP 2; long *pix; pix=malloc(PPR*PPR*sizeof(long)); fread(pix,BPP,PPR*PPR,in);

    But since the data come in 2-byte chunks (BPP=2) but sizeof(long)=4, fread() packs the data densely inside the allocated memory rather than packing them into long-sized parcels. Thus I end up with two rows packed together into one and the second half of the picture empty.

    I’ve changed it to loop over the number of pixels and read two bytes each time and store them in the allocated memory instead:

    for (m=0;m<PPR*PPR;m++) {   b1=fgetc(in);   b2=fgetc(in);   *(pix+m)=256*b1+b2; }
    • 0