LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
October 2009
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
2009.10.29 18:21 "Re: Tiff Digest, Vol 65, Issue 9", by Toby Thain
On 29-Oct-09, at 1:43 PM, Richard Nolde wrote: > I cannot check tiffcrop today as I have to rush off to a meeting > through > 18" of snow but I am aware of the warnings. They derive from the way I > read and pack data of various bit depths by casting an address to a > various sizes in order to grab only 8,16,24, or 32 bits from a given > memory location. I could probably use unions but it will take some > time > to check the results. I don't think union will help you much here. You can avoid pointer casts like the one on line 2817 buff1 = *((uint16 *)swapbuff); by open coding, e.g. buff1 = (src[0] << 8) | src[1]; // if source data is BigEndian or buff1 = (src[1] << 8) | src[0]; // if LittleEndian As well as being platform independent, this should be simpler. --T > The functions in question deal with the > endianness of the data on the fly, so it may take some time to silence > the warnings and test. > > As far as I know, the tiffcrop code in 3.9.* and 4.0 should all be the > same so any differences in warnings would be the result of changes in > build flags and/or include files. > > Richard Nolde > On 10/29/2009 11:00 AM, tiff-request@lists.maptools.org wrote: >> Send Tiff mailing list submissions to >> tiff@lists.maptools.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.maptools.org/mailman/listinfo/tiff >> or, via email, send a message with subject or body 'help' to >> tiff-request@lists.maptools.org >> >> You can reach the person managing the list at >> tiff-owner@lists.maptools.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Tiff digest..." >> >> >> Today's Topics: >> >> 1. Re: extending tags in "a"ppend mode? (Juergen Buchmueller) >> 2. Re: Number of images in a multi-tiff file? (Mark Pereira) >> 3. Re: extending tags in "a"ppend mode? - solved >> (Juergen Buchmueller) >> 4. Libtiff release soon, please advise (Bob Friesenhahn) >> 5. Re: Libtiff release soon, please advise (Edward Lam) >> 6. Re: Libtiff release soon, please advise (Bob Friesenhahn) >> 7. Re: Libtiff release soon, please advise (Edward Lam) >> 8. Re: Libtiff release soon, please advise (Bob Friesenhahn) >> >> >> --------------------------------------------------------------------- >> - >> >> Message: 1 >> Date: Wed, 28 Oct 2009 18:41:23 +0100 >> From: Juergen Buchmueller<pullmoll@t-online.de> >> Subject: Re: [Tiff] extending tags in "a"ppend mode? >> To: tiff@lists.maptools.org >> Message-ID:<20091028184123.aef7f387.pullmoll@t-online.de> >> Content-Type: text/plain; charset=US-ASCII >> >> On Wed, 28 Oct 2009 17:28:34 +0100 >> Juergen Buchmueller<pullmoll@t-online.de> wrote: >> >> >>> See attachment. This crashes when I try to run it on the file: >>> >> Funny enough the crash goes away if I choose a different name for >> my own >> tags. Perhaps a collision or lazy assumption with the autogenerated >> names (which would be the same)? >> >> - snprintf(buff, sizeof(buff), "Tag %d", id); >> + snprintf(buff, sizeof(buff), "test%d", id); >> >> Now the test program runs without error message, yet the TIFF file >> doesn't contain the new tags. Hmm... >> >> Juergen >> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 28 Oct 2009 23:17:13 +0530 >> From: Mark Pereira<mark@softjin.com> >> Subject: Re: [Tiff] Number of images in a multi-tiff file? >> To: Frank Warmerdam<warmerdam@pobox.com> >> Cc: tiff@lists.maptools.org >> Message-ID:<4AE883A1.4080908@softjin.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Thanks Frank for these clarifications ! >> >> Mark >> >> Frank Warmerdam wrote: >> >>> Brad Hards wrote: >>> >>> >>>> On Wednesday 28 October 2009 20:01:21 Mark Pereira wrote: >>>> >>>> >>>>> Is there a way to know the number of images present in a multi- >>>>> tiff file >>>>> in constant time. >>>>> >>>>> >>>> TIFFNumberOfDirectories() ? >>>> >>>> >>> Mark, >>> >>> No, there is not since the directory list needs to be walked to >>> count them. >>> The count is not available in a header or anything like that. >>> >>> Skimming the code briefly it appears that TIFFNumberOfDirectories >>> () is careful >>> to read the minimum amount of information from the file (a few >>> numbers from >>> the start of each directory) to count through the file so the >>> cost should >>> be minimal, but not constant time. >>> >>> Best regards, >>> >>> >> >> >> Business Disclaimer >> ____________________________________________________________ >> This e-mail message and any files transmitted with it are intended >> solely >> for the use of the individual or entity to which they are >> addressed. It >> may contain confidential, proprietary or legally privileged >> information. >> If you are not the intended recipient please be advised that >> you have >> received this message in error and any use is strictly >> prohibited. Please >> immediately delete it and all copies of it from your system, >> destroy any >> hard copies of it and notify the sender by return mail. You >> must not, >> directly or indirectly, use, disclose, distribute, print, or >> copy any part of >> this message if you are not the intended recipient. >> ___________________________________________________________ >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: http://lists.maptools.org/mailman/private/tiff/attachments/ >> 20091028/0357175c/attachment-0001.htm >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 28 Oct 2009 18:46:30 +0100 >> From: Juergen Buchmueller<pullmoll@t-online.de> >> Subject: Re: [Tiff] extending tags in "a"ppend mode? - solved >> To: tiff@lists.maptools.org >> Message-ID:<20091028184630.26999537.pullmoll@t-online.de> >> Content-Type: text/plain; charset=US-ASCII >> >> Ok, the problem seems to be solved now. >> >> I need to choose tag names different from the ones that libtiff would >> use on the auto-registration when reading a file, and I need to call >> TIFFWriteDirectory() after writing the tags and before closing the >> file >> again. >> >> Perhaps this little episode helps others in similiar situations. >> >> Cheers, >> Juergen >> >> >> ------------------------------ >> >> Message: 4 >> Date: Wed, 28 Oct 2009 17:43:33 -0500 (CDT) >> From: Bob Friesenhahn<bfriesen@simple.dallas.tx.us> >> Subject: [Tiff] Libtiff release soon, please advise >> To: Tiff List<tiff@lists.maptools.org> >> Message-ID: >> <alpine.GSO.2.01.0910281737540.1964@freddy.simplesystems.org> >> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII >> >> I plan to cut new libtiff releases soon. While I don't intend to fix >> all existing (or many) known bugs before those releases are cut (and >> there are many bugs listed in libtiff bugzilla), this would be a good >> time to remind of any dire issues known to exist which should >> definitely be fixed before a libtiff release. >> >> The bug tracker for libtiff is here: >> >> http://bugzilla.maptools.org/buglist.cgi?product=libtiff >> >> Thanks, >> >> Bob >> -- >> Bob Friesenhahn >> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/ >> bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> >> >> ------------------------------ >> >> Message: 5 >> Date: Wed, 28 Oct 2009 22:27:04 -0400 >> From: Edward Lam<edward@sidefx.com> >> Subject: Re: [Tiff] Libtiff release soon, please advise >> To: Bob Friesenhahn<bfriesen@simple.dallas.tx.us> >> Cc: Tiff List<tiff@lists.maptools.org> >> Message-ID:<4AE8FD78.1050704@sidefx.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Bob Friesenhahn wrote: >> >>> I plan to cut new libtiff releases soon. While I don't intend to >>> fix >>> all existing (or many) known bugs before those releases are cut (and >>> there are many bugs listed in libtiff bugzilla), this would be a >>> good >>> time to remind of any dire issues known to exist which should >>> definitely be fixed before a libtiff release. >>> >> I only looked at what caught my eye on the list. Bug 2001 seems like >> important low hanging fruit to do before final release: >> http://bugzilla.maptools.org/show_bug.cgi?id=2001 >> >> Basically, it is saying that we should be adding -fno-strict- >> aliasing to >> the gcc (3+?) compiler options when compiling with -O2. Probably >> none of >> libtiff was written with strict aliasing in mind? If so, it sounds >> like >> a good and easy thing to do for avoiding potential bad code >> generation. >> >> Regards, >> -Edward >> >> >> ------------------------------ >> >> Message: 6 >> Date: Wed, 28 Oct 2009 21:58:53 -0500 (CDT) >> From: Bob Friesenhahn<bfriesen@simple.dallas.tx.us> >> Subject: Re: [Tiff] Libtiff release soon, please advise >> To: Edward Lam<edward@sidefx.com> >> Cc: Tiff List<tiff@lists.maptools.org> >> Message-ID: >> <alpine.GSO.2.01.0910282139070.1964@freddy.simplesystems.org> >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Wed, 28 Oct 2009, Edward Lam wrote: >> >>> I only looked at what caught my eye on the list. Bug 2001 seems like >>> important low hanging fruit to do before final release: >>> http://bugzilla.maptools.org/show_bug.cgi?id=2001 >>> >>> Basically, it is saying that we should be adding -fno-strict- >>> aliasing to the >>> gcc (3+?) compiler options when compiling with -O2. Probably none >>> of libtiff >>> was written with strict aliasing in mind? If so, it sounds like a >>> good and >>> easy thing to do for avoiding potential bad code generation. >>> >> I agree that these issues should be avoided, but don't think that >> -fno-strict-aliasing is the answer since it surely makes the code >> slower. I did fix many of the aliasing warnings. The CVS HEAD >> version only produces these from the library code: >> >> libtiff/tif_dirread.c: In function 'TIFFFetchNormalTag': >> libtiff/tif_dirread.c:2922: warning: dereferencing pointer 'value. >> 235' does break strict-aliasing rules >> libtiff/tif_dirread.c:2922: note: initialized from here >> libtiff/tif_dirread.c:2942: warning: dereferencing pointer 'value. >> 239' does break strict-aliasing rules >> libtiff/tif_dirread.c:2942: note: initialized from here >> >> Several utilities produce such warnings, and particularly 'tiffcrop' >> in CVS HEAD spews lots of them. >> >> The libtiff from CVS branch-3-9 (which would be 3.9.2) produces no >> aliasing warnings from the library, and just a few warnings about >> uninitialized variables in some of the utilities. I am not sure why >> tiffcrop in branch-3-9 does not spew the same sort of warnings >> that it >> does in CVS HEAD, but I suspect that it was developed against release >> 3.9.X code. >> >> The GCC (4.4.2) flags used for testing compilation are >> >> -g -O2 -Wall -Winline -W -Wformat-security -Wpointer-arith >> -Wdisabled-optimization -Wno-unknown-pragmas >> >> Can you please re-check your builds with CVS libtiff and see if you >> see similar results? >> >> Bob >> -- >> Bob Friesenhahn >> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/ >> bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> >> >> ------------------------------ >> >> Message: 7 >> Date: Wed, 28 Oct 2009 23:54:45 -0400 >> From: Edward Lam<edward@sidefx.com> >> Subject: Re: [Tiff] Libtiff release soon, please advise >> To: Bob Friesenhahn<bfriesen@simple.dallas.tx.us> >> Cc: Tiff List<tiff@lists.maptools.org> >> Message-ID:<4AE91205.2050407@sidefx.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Bob Friesenhahn wrote: >> >>> On Wed, 28 Oct 2009, Edward Lam wrote: >>> >>>> I only looked at what caught my eye on the list. Bug 2001 seems >>>> like >>>> important low hanging fruit to do before final release: >>>> http://bugzilla.maptools.org/show_bug.cgi?id=2001 >>>> >>>> >>> I agree that these issues should be avoided, but don't think that >>> -fno-strict-aliasing is the answer since it surely makes the code >>> slower. I did fix many of the aliasing warnings. The CVS HEAD >>> version >>> only produces these from the library code: >>> ...<snip> ... >>> >> That's fine if someone has/will look at these to determine if they're >> real problems. I haven't. :) >> >> >>> Several utilities produce such warnings, and particularly >>> 'tiffcrop' in >>> CVS HEAD spews lots of them. >>> >> It's probably easy to introduce unless we build with the extra >> -Wstrict-aliasing=2 compiler? >> >> >>> The libtiff from CVS branch-3-9 (which would be 3.9.2) produces no >>> aliasing warnings from the library, and just a few warnings about >>> uninitialized variables in some of the utilities. >>> >> Sorry, I had somehow mistakenly thought that we were looking at a 4.0 >> release. :embarrassed: >> >> >>> Can you please re-check your builds with CVS libtiff and see if >>> you see >>> similar results? >>> >> I'm not sure if this is directed to me in particular. I had not >> checked >> in the first place since my usual development platform is on Win64. I >> trust your results are correct. :) >> >> Regards, >> -Edward >> >> >> >> ------------------------------ >> >> Message: 8 >> Date: Thu, 29 Oct 2009 10:22:56 -0500 (CDT) >> From: Bob Friesenhahn<bfriesen@simple.dallas.tx.us> >> Subject: Re: [Tiff] Libtiff release soon, please advise >> To: Edward Lam<edward@sidefx.com> >> Cc: Tiff List<tiff@lists.maptools.org> >> Message-ID: >> <alpine.GSO.2.01.0910291017380.1964@freddy.simplesystems.org> >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Wed, 28 Oct 2009, Edward Lam wrote: >> >> >>> It's probably easy to introduce unless we build with the extra >>> -Wstrict-aliasing=2 compiler? >>> >> I am not familiar with that one yet. >> >> >>>> The libtiff from CVS branch-3-9 (which would be 3.9.2) produces >>>> no aliasing >>>> warnings from the library, and just a few warnings about >>>> uninitialized >>>> variables in some of the utilities. >>>> >>> Sorry, I had somehow mistakenly thought that we were looking at a >>> 4.0 >>> release. :embarrassed: >>> >> To clarify, I expect to cut a release from both HEAD and branch-3-9, >> but the HEAD release would be just another beta. It is not fair >> doing >> one without the other and they both include similar improvements. >> >> >>> I'm not sure if this is directed to me in particular. I had not >>> checked in >>> the first place since my usual development platform is on Win64. >>> I trust your >>> results are correct. :) >>> >> I did see a couple of bug reports about warnings under Win64 and >> think >> they are still open. Since I don't have it, I don't test on it. >> >> Bob >> -- >> Bob Friesenhahn >> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/ >> bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> >> >> ------------------------------ >> >> _______________________________________________ >> Tiff mailing list >> Tiff@lists.maptools.org >> http://lists.maptools.org/mailman/listinfo/tiff >> >> End of Tiff Digest, Vol 65, Issue 9 >> *********************************** >> >> >> > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/