2009.10.28 09:01 "[Tiff] Number of images in a multi-tiff file?", by Mark Pereira

2009.10.29 17:43 "Re: [Tiff] Tiff Digest, Vol 65, Issue 9", by Richard Nolde

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. 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

> 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

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.

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

> End of Tiff Digest, Vol 65, Issue 9
> ***********************************
>
>
>