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 2008

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

2008.05.23 18:55 "Unitialized Variable Caused a Problem in TIFFCP", by Gene Amtower
2008.05.23 21:36 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Bob Friesenhahn
2008.05.23 23:50 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Gene Amtower
2008.05.24 01:15 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Bob Friesenhahn
2008.05.24 03:05 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Gene Amtower
2008.05.24 15:34 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Bob Friesenhahn
2008.05.26 17:11 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Gene Amtower
2008.05.27 04:07 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Bob Friesenhahn
2008.05.28 09:50 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Gerben Vos
2008.05.24 04:30 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Gene Amtower

2008.05.26 17:11 "Re: Unitialized Variable Caused a Problem in TIFFCP", by Gene Amtower

On Sat, 2008-05-24 at 10:34 -0500, Bob Friesenhahn wrote:
> I don't see any samples-per-pixel tag in the above output so I expect 
> that the reported libtiff defect is due to using the wrong interface 
> to obtain the tag. The TIFFGetFieldDefaulted() function should be used 
> rather than TIFFGetField().  If TIFFGetField() is used, then it is 
> necessary to verify that the return value is 1 before deciding to use 
> the result.
> 
> This seems to be quite rare, and perhaps violates the TIFF 
> specification.

I was of the same opinion, as I suspect the software that is generating
the problem images could be over 10 years old.  As such, I hate to say
this is a code problem and add code to the release to correct a data
problem, but I'll defer to those who work with this package regularly.
For my usage, I've defaulted the subject variable to "1" to avoid the
error message with my images.

> 3.9.0beta contains important bug fixes.  The focus has been on libtiff 
> 4.0, which is a feature release (BigTIFF support).

I copied my watermarking additions to the 4.0.0beta2 code package, then
recompiled and tested.  I noticed that the 'bias' routine had some minor
restructuring for error conditions, and I updated my 'watermark' routine
accordingly.  For my usage, it's working great.

I know my code doesn't manage all potential input file formats - i.e.
more work is required to allow watermarking for colored images.  Hence,
it may not be "ready for prime time".  I played with different methods
to watermark the images, but my final method of applying the watermark
image is through a bit-level 'or' of the two image 'values' because my
image and watermark files are b/w.  Each input value contained a pixel
per bit, so I had to work at a bit-level rather than a value-level to
get the desired output.  Others may have watermarking needs that I have
not included, so this function may work incorrectly for their images.

Should I submit any code to the team?  Being new to this process, how
would I do that?  (file attachment?  CVS access?  other?)  I know it's
not the most important thing on the libtiff list, but I want to "feed"
my effort back to the team to help bring down the MS mother-ship.  I
didn't see anyone submitting new functionality in my review of the last
6 months of list postings, so I'm a bit in the dark on how to proceed.

Thanks for the help,

   Gene