AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2005.03.30 10:19 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Priyanshu Sharma
2005.03.30 00:18 "[Tiff] RFC: fast 'copy free' tiff decoding", by Ron
2005.03.30 10:45 "Re[2]: [Tiff] RFC: fast 'copy free' tiff decoding", by Jean-Yves Le Ridant
2005.03.30 11:02 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Joris
2005.04.29 22:52 "[Tiff] Color TIFF/JPEG compression questions", by Frank, Jason
2005.05.03 11:35 "[Tiff] TIFFReadRGBAImage problem", by katrina maramba
2005.05.04 08:47 "[Tiff] Is this possible?", by katrina maramba
2005.05.05 05:17 "[Tiff] TIFF2PDF Bug resolved + proposed enhancement", by Bruno LEDOUX
2005.05.05 08:44 "[Tiff] OT (tiff but not libtiff) - storing values in the offset", by Antoine
2005.05.05 19:26 "[Tiff] TiffScanlineSize", by Jean Yves LE RIDANT
2005.05.11 11:57 "[Tiff] How to compile Libtiff under Borland C++ Builder 6.0", by
2005.05.12 11:06 "[Tiff] LibTiffDelphi and CLX problem", by Kamil Gola
[...]

2005.03.30 10:19 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Priyanshu Sharma

Hey Ron

   Are u planning to come up with new library that will replace LIBTIFF..???
What is this all about

On Wed, 30 Mar 2005 15:47:52 +0530, Priyanshu Sharma <priyanshu.sharma@gmail.com> wrote:

> hey Ron.
>
>

> On Wed, 30 Mar 2005 04:27:02 -0500 (EST),
> tiff-request@remotesensing.org <tiff-request@remotesensing.org> wrote:
> > Send Tiff mailing list submissions to
> >         tiff@remotesensing.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         http://xserve.flids.com/mailman/listinfo/tiff
> > or, via email, send a message with subject or body 'help' to
> >         tiff-request@remotesensing.org
> >
> > You can reach the person managing the list at
> >         tiff-owner@remotesensing.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Tiff digest..."
> >
> > Today's Topics:
> >
> >    1. RFC: fast 'copy free' tiff decoding (Ron)
> >    2. Re: RFC: fast 'copy free' tiff decoding (Andy Cave)
> >    3. Re: RFC: fast 'copy free' tiff decoding (Ron)
> >    4. Re: RFC: fast 'copy free' tiff decoding (Bob Friesenhahn)
> >    5. Re: RFC: fast 'copy free' tiff decoding (Edward Lam)
> >    6. Re: RFC: fast 'copy free' tiff decoding (Ron)
> >    7. Re: RFC: fast 'copy free' tiff decoding (Joris)
> >    8. Re[2]: [Tiff] RFC: fast 'copy free' tiff decoding
> >       (Jean-Yves Le Ridant)
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 30 Mar 2005 09:48:02 +0930
> > From: Ron <ron@debian.org>
> > Subject: [Tiff] RFC: fast 'copy free' tiff decoding
> > To: tiff@remotesensing.org
> > Message-ID: <20050330001802.GB4298@hank.shelbyville.oz>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Hi,
> >
> > I'm a little uncertain where to start with this one, since its
> > certainly going to be much more intrusive than anything I've
> > proposed to date and I really haven't been here very long to be
> > suggesting major upheavals, so bear with me and feel free to
> > bring as big a cluebat as you need.
> >
> > It occurs to me that tiff was largely designed to be trivially
> > implemented in hardware.  I'd like to more actively exploit that
> > on platforms where we can and I think we can pick up a lot of
> > other niceties (like generic IFD support) very easily along the
> > way.
> >
> > The basic idea is very simple.  First map a tiff into memory,
> > then cast carefully constructed C structures into the right
> > offsets of that memory space to be able to access the data
> > directly.
> >
> > I have a proof of concept in C++ that simply mmap's the entire
> > file in one go, then walks the offset chain casting structures
> > into place to dump the header and the tags in each IFD.
> > Everything is available, but nothing is actually copied (or
> > potentially even paged in on a modern system) until you access
> > the members of the structures (which correspond to the elements
> > in the now decomposed tiff).  No attempt is made to interpret
> > anything beyond the most basic structure so any tiff, baseline
> > or private spec, may be accessed this way.  Conformance with
> > those standards and any needed codecs etc. can be cleanly
> > layered on top.  It can also be made to degrade nicely if the
> > tiff cannot be mmap'ed, or if only one tile at at time can be
> > etc.
> >
> > The question now, is where to flesh that out.  I'm not really
> > interested in forking a 'competitor' to libtiff (for all the
> > usual long term time budget reasons), but this is a pretty big
> > tangent to throw you people on if you are busy stabilising what
> > you already have.  OTOH it seems like a very solid core to build
> > some of the other things we want upon, we get generic tiff for
> > free, and simply need to layer baseline tiff and all the other
> > stuff on top of that.
> >
> > Is anybody else here interested in following that chain of
> > thought?  There are plenty of other real details I can flesh
> > this out with for people who are.  Would it be reasonable to run
> > an experimental branch of the libtiff cvs to shake some of these
> > ideas out?  I could whip up something more C friendly along
> > these lines to kick start that off if there was sufficient
> > interest.
> >
> > best,
> > Ron
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 30 Mar 2005 01:24:18 +0100
> > From: "Andy Cave" <andy.cave@hamillroad.com>
> > Subject: Re: [Tiff] RFC: fast 'copy free' tiff decoding
> > To: <tiff@remotesensing.org>, "Ron" <ron@debian.org>
> > Message-ID: <042101c534be$d0b4af20$0200a8c0@PLATO>
> > Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> >         reply-type=original
> >
> > Hi Ron.
> >
> > Obvious question - how do you cope with 'values' that need to be byte
> > swapped?
> >
> > Andy.
> >
> > ----- Original Message -----
> > From: "Ron" <ron@debian.org>
> > To: <tiff@remotesensing.org>
> > Sent: Wednesday, March 30, 2005 1:18 AM
> > Subject: [Tiff] RFC: fast 'copy free' tiff decoding
> >
> > >
> > > Hi,
> > >
> > > I'm a little uncertain where to start with this one, since its
> > > certainly going to be much more intrusive than anything I've
> > > proposed to date and I really haven't been here very long to be
> > > suggesting major upheavals, so bear with me and feel free to
> > > bring as big a cluebat as you need.
> > >
> > > It occurs to me that tiff was largely designed to be trivially
> > > implemented in hardware.  I'd like to more actively exploit that
> > > on platforms where we can and I think we can pick up a lot of
> > > other niceties (like generic IFD support) very easily along the
> > > way.
> > >
> > > The basic idea is very simple.  First map a tiff into memory,
> > > then cast carefully constructed C structures into the right
> > > offsets of that memory space to be able to access the data
> > > directly.
> > >
> > > I have a proof of concept in C++ that simply mmap's the entire
> > > file in one go, then walks the offset chain casting structures
> > > into place to dump the header and the tags in each IFD.
> > > Everything is available, but nothing is actually copied (or
> > > potentially even paged in on a modern system) until you access
> > > the members of the structures (which correspond to the elements
> > > in the now decomposed tiff).  No attempt is made to interpret
> > > anything beyond the most basic structure so any tiff, baseline
> > > or private spec, may be accessed this way.  Conformance with
> > > those standards and any needed codecs etc. can be cleanly
> > > layered on top.  It can also be made to degrade nicely if the
> > > tiff cannot be mmap'ed, or if only one tile at at time can be
> > > etc.
> > >
> > > The question now, is where to flesh that out.  I'm not really
> > > interested in forking a 'competitor' to libtiff (for all the
> > > usual long term time budget reasons), but this is a pretty big
> > > tangent to throw you people on if you are busy stabilising what
> > > you already have.  OTOH it seems like a very solid core to build
> > > some of the other things we want upon, we get generic tiff for
> > > free, and simply need to layer baseline tiff and all the other
> > > stuff on top of that.
> > >
> > > Is anybody else here interested in following that chain of
> > > thought?  There are plenty of other real details I can flesh
> > > this out with for people who are.  Would it be reasonable to run
> > > an experimental branch of the libtiff cvs to shake some of these
> > > ideas out?  I could whip up something more C friendly along
> > > these lines to kick start that off if there was sufficient
> > > interest.
> > >
> > > best,
> > > Ron
> > >
> > >
> > > _______________________________________________
> > > Tiff mailing list
> > > Tiff@remotesensing.org
> > > http://xserve.flids.com/mailman/listinfo/tiff
> > >
> > >
> > >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 30 Mar 2005 10:23:11 +0930
> > From: Ron <ron@debian.org>
> > Subject: Re: [Tiff] RFC: fast 'copy free' tiff decoding
> > To: tiff@remotesensing.org
> > Message-ID: <20050330005311.GC4298@hank.shelbyville.oz>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Wed, Mar 30, 2005 at 01:24:18AM +0100, Andy Cave wrote:
> > > Hi Ron.
> > >
> > > Obvious question - how do you cope with 'values' that need to be byte
> > > swapped?
> >
> > Obvious answer - on demand :-)  In C++ that's almost natural if you
> > provide accessors to the members.  In C we'd just move the accessor
> > methods out of the structure where required.  In some cases, like
> > 'converting' packed ABGR to RGBA pixels, we can actually exploit the
> > fact that things appear 'swapped' on some systems to once again simply
> > 'recast' the data into a structure where the order appears more
> > appropriate (or is named and hence irrelevant to the user).
> >
> > The precise layout of some structures may depend on the byte sex of
> > the host system, but the code that uses them should not need to care
> > or know about that.
> >
> > cheers,
> > Ron
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 29 Mar 2005 21:30:20 -0600 (CST)
> > From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
> > Subject: Re: [Tiff] RFC: fast 'copy free' tiff decoding
> > To: Ron <ron@debian.org>
> > Cc: tiff@remotesensing.org
> > Message-ID: <Pine.SOC.4.60.0503292118290.8945@blade.simplesystems.org>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> >
> > On Wed, 30 Mar 2005, Ron wrote:
> > >
> > > The basic idea is very simple.  First map a tiff into memory,
> > > then cast carefully constructed C structures into the right
> > > offsets of that memory space to be able to access the data
> > > directly.
> >
> > What problem are you trying to solve?  Fixing the private IFD access
> > should not require re-implementing the whole library! :-)
> >
> > I agree that mmap() is cool, but libtiff already uses it to read
> > files, just not quite as efficiently as it could.  Requiring mmap()
> > would make libtiff less portable.
> >
> > Based on my own testing, libtiff's performance is quite good.  The
> > library is very robust and well tested.
> >
> > Bob
> > ======================================
> > Bob Friesenhahn
> > bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> > GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Tue, 29 Mar 2005 23:51:39 -0500
> > From: Edward Lam <edward@sidefx.com>
> > Subject: Re: [Tiff] RFC: fast 'copy free' tiff decoding
> > To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
> > Cc: tiff@remotesensing.org
> > Message-ID: <424A305B.2010804@sidefx.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Bob Friesenhahn wrote:
> > > Based on my own testing, libtiff's performance is quite good.  The
> > > library is very robust and well tested.
> >
> > Has anyone done any profiling in order to find out what type of bottlenecks
> > currently exist in libtiff?
> >
> > -Edward
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Wed, 30 Mar 2005 15:25:11 +0930
> > From: Ron <ron@debian.org>
> > Subject: Re: [Tiff] RFC: fast 'copy free' tiff decoding
> > To: tiff@remotesensing.org
> > Message-ID: <20050330055510.GA10045@hank.shelbyville.oz>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Tue, Mar 29, 2005 at 09:30:20PM -0600, Bob Friesenhahn wrote:
> > > On Wed, 30 Mar 2005, Ron wrote:
> > > >
> > > >The basic idea is very simple.  First map a tiff into memory,
> > > >then cast carefully constructed C structures into the right
> > > >offsets of that memory space to be able to access the data
> > > >directly.
> > >
> > > What problem are you trying to solve?
> >
> > How to handle subsets of the available data is probably the most
> > pressing one.  Without handling them more than necessary and without
> > losing data that I have incomplete knowledge about.
> >
> > I want to be able to read/write baseline tiffs, and to be able to examine
> > and manipulate exif data in them, and also to do the same with exif data
> > found in some jpeg images.  (other private IFD's should be a cinch once
> > all that is easy)
> >
> > What I don't want to do is exhaustively hand code copy operations to
> > extract and verify every possible tag and IFD and copy them and their
> > values into (distorted) mirror structures before being able to access
> > any part of that, or to pass that information to other parts of my code.
> > At least not before having a good general solution that catches all
> > the ones we have not yet specialised by default.  And either way, I
> > don't want to be forced to decide whether to keep the 'original' tiff
> > in memory, or just the processed copy, or worse both, when unless the
> > image data in it is compressed etc. they are essentially the same data
> > slightly reshuffled.
> >
> > > Fixing the private IFD access
> > > should not require re-implementing the whole library! :-)
> >
> > Most certainly.  And indeed neither should this I think.  It would
> > break the current abi because the TIFF structure would have some common
> > parts removed from it and reordered, but the essential functions of the
> > library would go almost completely unchanged.  Or at least could where
> > retaining source compatibility with old code was pre-eminent.
> >
> > The pro for doing that is we then have some very nice public structures
> > which users can pass about in their code, and which don't need to
> > be put through a translation function to turn them back into the 'stuff
> > of tiffs' since they are one and the same.
> >
> > I'm raising this here precisely because I don't want to reimplement
> > the whole lib, most of the functionality is fine, but we need a nice
> > (set of) data structure(s) to pass this information around in and
> > that's the angle I've been looking at this from.
> >
> > I was able to decompose a tiff like this (including the non-baseline
> > hunk out of a jpeg APP0 section) with just a few lines of code that
> > did not use libtiff at all.  Getting existing libtiff to read from those
> > structures does not seem terribly daunting, but the question of whether
> > it is in fact a good idea to do is of course still open.  :-)
> >
> > > I agree that mmap() is cool, but libtiff already uses it to read
> > > files, just not quite as efficiently as it could.  Requiring mmap()
> > > would make libtiff less portable.
> >
> > Yes, this does not require mmap to be an advantage though, even without
> > it you can still more efficiently read a block of memory in by whatever
> > method you like and cast the correct data structure over it.  Then seek
> > and read another etc.
> >
> > > Based on my own testing, libtiff's performance is quite good.  The
> > > library is very robust and well tested.
> >
> >  From what I have seen of the code that is not surprising, I'm certainly
> > not suggesting this because of any performance bottle neck I've
> > measured, its the trouble I'm having with seeing how to get generic tiff
> > data in and out, and how to pass it around within my code efficiently.
> >
> > Having tiff data resemble a tiff would seem to be an advantage for a lot
> > of reasons though, so I would not be surprised if some gains for some
> > people were found in this respect too.
> >
> > Perhaps other people have some very simple strategy to the same end that
> > is better than this, but it would seem like we need to change at least
> > some things in a way that may not be compatible so I'd welcome any clues
> > on how others see this may all unfold.
> >
> > Right now I can trivially extract:
> >
> > Tiff: using memory mapped source
> > Tiff: byte sex = 4949
> > Tiff: version  = 2a
> > Tiff: first IFD at 8
> > Tiff: 49  49  2a  0  8  0  0  0  b  0  e  1  2  0  20  0  0  0  92  0
> > Tiff: IFD 1 has 11 tags
> > Tiff: next IFD offset = 792
> > Tiff: IFD 1 at 0xb7b76008, tags at 0xb7b7600a
> > Tiff: tag: 270, type 2, count 32, value: 146
> > Tiff: tag: 271, type 2, count 24, value: 178
> > Tiff: tag: 272, type 2, count 7, value: 202
> > Tiff: tag: 274, type 3, count 1, value: 1
> > Tiff: tag: 282, type 5, count 1, value: 216
> > Tiff: tag: 283, type 5, count 1, value: 224
> > Tiff: tag: 296, type 3, count 1, value: 2
> > Tiff: tag: 305, type 2, count 8, value: 232
> > Tiff: tag: 306, type 2, count 20, value: 264
> > Tiff: tag: 531, type 3, count 1, value: 2
> > Tiff: tag: 34665, type 4, count 1, value: 284
> > Tiff: has exif IFD
> > Tiff: exif IFD has 24 tags
> > Tiff: next IFD offset = 0
> > Tiff: exif tag: 33434, type 5, count 1, value: 578
> > Tiff: exif tag: 33437, type 5, count 1, value: 586
> > Tiff: exif tag: 34850, type 3, count 1, value: 3
> > Tiff: exif tag: 34855, type 3, count 1, value: 100
> > Tiff: exif tag: 36864, type 7, count 4, value: 808530480
> > Tiff: exif tag: 36867, type 2, count 20, value: 594
> > Tiff: exif tag: 36868, type 2, count 20, value: 614
> > Tiff: exif tag: 37121, type 7, count 4, value: 197121
> > Tiff: exif tag: 37122, type 5, count 1, value: 634
> > Tiff: exif tag: 37380, type 10, count 1, value: 642
> > Tiff: exif tag: 37381, type 5, count 1, value: 650
> > Tiff: exif tag: 37383, type 3, count 1, value: 5
> > Tiff: exif tag: 37384, type 3, count 1, value: 3
> > Tiff: exif tag: 37385, type 3, count 1, value: 0
> > Tiff: exif tag: 37386, type 5, count 1, value: 658
> > Tiff: exif tag: 37500, type 7, count 520, value: 916
> > Tiff: exif tag: 37510, type 7, count 125, value: 666
> > Tiff: exif tag: 40960, type 7, count 4, value: 808464688
> > Tiff: exif tag: 40961, type 3, count 1, value: 1
> > Tiff: exif tag: 40962, type 4, count 1, value: 1600
> > Tiff: exif tag: 40963, type 4, count 1, value: 1200
> > Tiff: exif tag: 40965, type 4, count 1, value: 886
> > Tiff: exif tag: 41728, type 7, count 1, value: 3
> > Tiff: exif tag: 41729, type 7, count 1, value: 1
> > Tiff: IFD 2 has 6 tags
> > Tiff: next IFD offset = 0
> > Tiff: IFD 2 at 0xb7b76318, tags at 0xb7b7631a
> > Tiff: tag: 259, type 3, count 1, value: 6
> > Tiff: tag: 282, type 5, count 1, value: 870
> > Tiff: tag: 283, type 5, count 1, value: 878
> > Tiff: tag: 296, type 3, count 1, value: 2
> > Tiff: tag: 513, type 4, count 1, value: 4084
> > Tiff: tag: 514, type 4, count 1, value: 4601
> >
> > Without needing to know anything more than the basic tiff IFD structure
> > (and the exif IFD pointer in this case), and pass this information to
> > other parts of my code without needing to copy (much) more than the
> > address of a pointer -- without fear of losing or misinterpreting any of
> > it along the way.
> >
> > If there is an even easier way, then I'm all ears...
> >
> > best,
> > Ron
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Wed, 30 Mar 2005 09:54:27 +0200
> > From: "Joris" <joris.at.lebbeke@skynet.be>
> > Subject: Re: [Tiff] RFC: fast 'copy free' tiff decoding
> > To: <tiff@remotesensing.org>
> > Message-ID: <001801c534fd$b30fe220$5b99f651@dfgrrxsknr4e>
> > Content-Type: text/plain;       charset="iso-8859-1"
> >
> > Ron,
> >
> > > How to handle subsets of the available data is probably the most
> > > pressing one.  Without handling them more than necessary and without
> > > losing data that I have incomplete knowledge about.
> >
> > May I resume your goal like this...?
> >
> > LibTiff offers no generic access to TIFF (Tag) data as it is. Instead, it goes a
> > long way interpreting (checking tag datatype and count for starters), and next
> > offers tag specific access that may be substantially different from the original
> > tag data (like is the case with the Colormap tag, or even the count of the
> > BitsPerSample tag). That is fine if your code at some point really needs a
> > convinient single value for specifically the BitsPerSample tag, but it is a
> > bridge too far if you really need more generic access to the exact TIFF (Tag)
> > data of any tag, in any TIFF.
> >
> > What is needed is something like 'two layers' of data access here. The bottom
> > one being the one you propose to add, that simply offers exactly what is there
> > without doing any sorts of interpreting. This layer does not even need tag
> > definitions, it is tag ignorant. The next layer, is the layer we're used to in
> > LibTiff, the layer that is friendly in checking the tag values and interpreting
> > them, offering access to more higher level structures depending on the specific
> > tag in question.
> >
> > If this is your actual goal, I must say I find it a good and natural and correct
> > thought... At the risk of sounding boring: I've done the same in my native
> > Delphi TIFF codec. But it is a major rewrite to get it into LibTiff...
> >
> > If I'm interpreting your goals correctly, I'm afraid you might be confusing the
> > issue with all this talk about memory maps and other implementation issues. I've
> > personally always considered memory mapping TIFFs a bad idea. There's no telling
> > what size files you might need to handle, especially with the new BigTIFF
> > format. You could need to eat 8 gig of address space on a machine that is
> > theoretically limited to 2 gig for memory maps, and shares this 2 gig with other
> > applications, like I think is the case on common windows systems. Moreover,
> > there seems very little benefit to abusing address space like this, as opposed
> > to good ol' plain file IO, especially given the fact that you'll need to aling
> > and byteswap in seperately allocated memory blocks anyhow.
> >
> > Joris Van Damme
> > info@awaresystems.be
> > http://www.awaresystems.be/
> > Download your free TIFF tag viewer for windows here:
> > http://www.awaresystems.be/imaging/tiff/astifftagviewer.html
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Wed, 30 Mar 2005 11:20:44 +0200
> > From: Jean-Yves Le Ridant <jean-yves.leridant@culture.gouv.fr>
> > Subject: Re[2]: [Tiff] RFC: fast 'copy free' tiff decoding
> > To: tiff@remotesensing.org
> > Message-ID: <944108982.20050330112044@culture.gouv.fr>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > EL> Bob Friesenhahn wrote:
> > >> Based on my own testing, libtiff's performance is quite good.  The
> > >> library is very robust and well tested.
> >
> > EL> Has anyone done any profiling in order to find out what type of bottlenecks
> > EL> currently exist in libtiff?
> >
> > I've heard of well known tif viewers whose speed,
> > ( on a windoze system ... ) drop down dramatically
> > as soon as RAM allocated to them is not three time
> > the size of uncompressed tif file.
> >
> > Forgot the name ...
> >
> > For my experience, opening "mapped" on windows system,
> > - with the standard fopen(".tif", "r") -
> > if you have a lot RAM .....
> >
> > --
> > Jean-Yves
> >
> > ------------------------------
> >
> > _______________________________________________
> > Tiff mailing list
> > Tiff@remotesensing.org
> > http://xserve.flids.com/mailman/listinfo/tiff
> >
> > End of Tiff Digest, Vol 10, Issue 15
> > ************************************
> >
>