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
October 2005

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

2005.10.22 13:47 "checking test images", by <ryuki_dono@yahoo.de>
2005.10.25 11:25 "Re: checking test images", by <ryuki_dono@yahoo.de>
2005.10.25 13:38 "Re: checking test images", by Frank Warmerdam
2005.10.25 14:37 "Re: checking test images", by Bob Friesenhahn
2005.10.26 12:06 "Re: checking test images", by <ryuki_dono@yahoo.de>
2005.10.26 14:43 "Re: checking test images", by Frank Warmerdam
2005.10.26 17:47 "Re: checking test images", by <ryuki_dono@yahoo.de>
2005.10.26 18:05 "Re: checking test images", by Bob Friesenhahn
2005.10.26 18:59 "Re: checking test images", by Joris Van Damme
2005.10.26 19:47 "Re: checking test images", by Bob Friesenhahn
2005.10.26 21:38 "Re: checking test images", by <ryuki_dono@yahoo.de>
2005.10.26 22:06 "Re: checking test images", by Frank Warmerdam

2005.10.26 21:38 "Re: checking test images", by <ryuki_dono@yahoo.de>

Bob Friesenhahn schrieb:
>
> Most applications don't qualify as "serious" applications.  For many 
> applications it is perfectly ok for 12 or 16 bit data is presented 
> with only 8 bits.  This is demonstrated by the fact that hardly any 
> computer display systems support more than 8 bits of grayscale 
> resolution.  So there is nothing wrong with libtiff offering built-in 
> support for reading other sizes as long as the user understands that 
> there is loss.
>
> There are "serious" applications where 12 or 16 bits are really 
> required.  Those applications will be written to support full resolution.

I think so too. In most cases there is no need for accurate data 
display. If you want to create a simple preview or thumbnails from tiff 
files the loss through downsampling doesn't matter. It depends on the 
application. From this point of view there is nothing wrong about a function 
like TIFFReadRGBAImage when it is clear that there is loss and overhead. For 
getting the precise data there are allways low level functions. An easy 
access to the codec is a plus too.

I tried to use the default errorhandler and under normal conditions it 
would be the best solution. Unfortunately I'm missing JPEG support. You 
can look at the errormessages I get for images like zackthecat.tif. While 
TIFFReadRGBAImage reads unsupported TIFF files, recovers from errors and 
give back a NULL, it crashes fatal here. For the moment I stick to the 
exception throwing.