AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
May 2010

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2010.05.11 15:32 "Tiff with varying bit depths", by Thomas Richter
2010.05.11 15:49 "Re: Tiff with varying bit depths", by Frank Warmerdam
2010.05.11 16:02 "Re: Tiff with varying bit depths", by Thomas Richter
2010.05.11 16:31 "Re: Tiff with varying bit depths", by Scott Ribe
2010.05.11 16:52 "Re: Tiff with varying bit depths", by Igor Skochinsky
2010.05.11 16:58 "Re: Tiff with varying bit depths", by Scott Ribe
2010.05.11 19:19 "Re: Tiff with varying bit depths", by Thomas Richter
2010.05.11 15:58 "Re: Tiff with varying bit depths", by Bob Friesenhahn
2010.05.11 20:16 "Re: Tiff with varying bit depths", by Joris Van Damme
2010.05.11 20:22 "Re: Tiff with varying bit depths", by Thomas Richter
2010.05.11 21:33 "Re: Tiff with varying bit depths", by Joris Van Damme

2010.05.11 19:19 "Re: Tiff with varying bit depths", by Thomas Richter

Igor Skochinsky wrote:
> Hi Scott,
> 
> The values make perfect sense to me.
> The image is 64x64 pixels, each pixel is 16 bits, so the strip size is
> 64*64*2 = 8192 bytes. Pixel data is split into three samples: 5, 6,
> and 5 bits for R, G and B.
> 
> Thomas,
> 
> Can you debug TIFFOpen() it and see which check fails? I expect that
> if you patch it, you should be able to use TIFFReadRawStrip() or maybe
> even TIFFReadEncodedStrip().

The code fails in TIFFFetchPerSampleShorts, called by TIFFReadDirectory 
(expected), called by TIFFClientOpen (probably unexpected). Thus libTIFF 
already parses the first directory from TIFFOpen(), which is documented 
behavior.

I also see from "man TIFFOpen" that the "h" flag prevents that, thus I 
could at least open the file, but then do what? If I cannot read the 
directory without falling over, how do I get at the bits per sample tag 
(which I still need, in one way or another).

I'm currently using ReadEncodedStripe() - or - ReadEncodedTile(), 
depending on whether the image is tiled or striped; would be great if I 
would be able to continue using that, but I nevertheless need the 
directory content.

Is there a way to patch up the directory *after* TIFFOpen(), but before 
TIFFReadDirectory() sees the file? For example, getting the bits per 
sample *manually* (without running into TIFFReadDirectory()), then 
patching that and the number of samples over, then calling 
TIFFReadDirectory(), and then fixing the mess again when reading the data?

So long,
	Thomas