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
Thread
2005.10.15 16:06 "Re: Small bug report, and error handler parameter issue", by Frank Warmerdam
On 10/15/05, Joris wrote:
> 1) In LibTiff 3.7.4, tif_write.c, line 520:
>
> if (tif->tif_dir.td_samplesperpixel == 1) {
> /*
> * Planarconfiguration is irrelevant in case of single band
> * images and need not be included. We will set it anyway,
> * because this field is used in other parts of library even
> * in the single band case.
> */
> tif->tif_dir.td_planarconfig == PLANARCONFIG_CONTIG;
> } else {
>
> ...This last '==' should, I think, be '='.
Joris,
I have applied this change.
> 2) The issue of the parameters of the warning and error handlers has
> come up before. I totally fail to do anything meaningfull with warning
> and errors in a context that envolves multiple TIFF * in a single
> thread, because there is no TIFF * parameter in the warning and error
> handler callbacks, and thus the warnings and errors can't be traced to
> their TIFF context and dealt with properly.
>
> I now find myself in a situation where I really need that. So I've
> extended the error handler with that TIFF * parameter, and changed all
> TIFFError and TIFFWarning calls in the core library accordingly. I
> haven't updated any of the tools, I don't know if it will seriously
> impact those. Is there any chance this could find its way into CVS, so
> that I don't have to change again with each new update? I'm pretty sure
> people are all for the ability to present error more meaningfull then
> 'The TIFF file can not be opened because there was an error opening the
> TIFF file', even when multiple TIFFs are involved. I can't build a diff,
> but I can send the complete edited sources for you more tools-enabled
> Linux guys to diff.
This change would break many existing applications that
use libtiff (as I understand the change), and thus I don't
think it could be contemplated except as part of a major
generational step, presumably to libtiff 4.0.
So, my position is that it should not be done till we are needing
to do alot of other disruption. These sort of API changes in a
stable and established library like libtiff cause alot of waves.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent