Return-Path: owner-tiff@olympiakos.com
Return-Path: <owner-tiff@olympiakos.com>
Received: from localhost (localhost [127.0.0.1])
	by at1895.spb.edu (8.12.1/8.12.1/Debian -1) with ESMTP id g16AbKt5003257
	for <dron@localhost>; Wed, 6 Feb 2002 13:41:04 +0300
Received: from eudoramail.com [209.185.123.45]
	by localhost with POP3 (fetchmail-5.9.0)
	for dron@localhost (single-drop); Wed, 06 Feb 2002 13:41:04 +0300 (MSK)
Received: from gate7.olympiakos.com ([207.176.88.85]) by shared1-mail.whowhere.com; Tue Feb  5 07:12:49 2002
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id JAA24457;
	Tue, 5 Feb 2002 09:57:48 -0500
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Tue, 5 Feb 2002 09:55:21 -0500
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id JAA24343
	for tiff-outgoing; Tue, 5 Feb 2002 09:55:21 -0500
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from web20502.mail.yahoo.com (web20502.mail.yahoo.com [216.136.226.137])
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id JAA24333
	for <tiff@olympiakos.com>; Tue, 5 Feb 2002 09:55:17 -0500
Message-ID: <20020205145509.75549.qmail@web20502.mail.yahoo.com>
Received: from [209.31.184.134] by web20502.mail.yahoo.com via HTTP; Tue, 05 Feb 2002 06:55:09 PST
Date: Tue, 5 Feb 2002 06:55:09 -0800 (PST)
From: Harring Figueiredo <harringf@yahoo.com>
Subject: Re: tiff (libtiff)
To: Jon Saxton <js@triton.vg>, tiff <tiff@olympiakos.com>
In-Reply-To: <20020205123324.VMTG21100.out010.verizon.net@proteus>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-tiff@olympiakos.com
Precedence: bulk
Status: RO
Content-Length: 4777
Lines: 115


  Thanks for the reply to all.

  Here are some answers to question I have been posted. The plataform is HPUX
11.0
   We are using CORBA (Constantly Outputs Real Bloated Applications --oops,
stepping out of my soap-box now :) , so no sockets are used at the high level.
   I cannot write a temp file because of performance issues ( We are talking
about possibly thousands of images). 

   

--- Jon Saxton <spam.free@verizon.net> wrote:
> ** Reply to message from Peter Montgomery <pjmonty@csi.com> on Sun, 03 Feb
> 2002
> 13:42:28 -0800
> 
> > Harring,
> > 
> > >   I would like to know how I can manipulate a TIFF image that is
> > already in
> > > memory ( I am receiving the image through the network ).
> > >   From what I can see in Libtiff, we can only get a handle to a Tiff
> > by opening
> > > a file.
> > 
> > Just curious, are you receiving the file directly over a socket?  My
> > confusion stems from the fact that if you have a harddrive on a network
> > and the drive is mapped to the local machine, then the library works
> > like it always does.  A network drive behaves no different from a local
> > drive since the OS hides the magic ju-ju needed and presents a normal
> > file handle.
> > 
> > Of course, if you are directly hooking up to a machine via a socket and
> > squirting bits down the pipe, then that's a different story.  The
> > simplest solution in that case is to simply write the incoming data to
> > disk as a temporary file and then handle it as usual.  The drawback is
> > that you have the added overhead of reading the image twice.  This could
> > be substantial depending on the image size.
> > 
> > I'm not sure of the best way to directly handle an image in memory, but
> > perhaps letting the list know what platform you're working on may be of
> > benefit to finding a solution.
> > 
> >     Thanks,
> >     PeterM
> 
> Oh boy, I shall follow this discussion with interest.
> 
> In 1997 when I first started manipulating (small) TIFF files a principal
> requirement was dealing with images in memory and I couldn't see how to do
> that
> with libtiff which seemed to do everything with disk files.  In UNIX
> environments that would be tolerable through memory-mapping but I was working
> in
> a networked PC environment.  Now perhaps in my naivety I didn't understand
> libtiff well enough but I chose to write my own TIFF handlers (originally in
> C,
> then later in C++) independent of libtiff with the exception of the CCITT
> G3/G4
> codecs which I carefully teased out of the file-oriented libtiff code.
> 
> My implementation was/is not as broad in scope as libtiff; it was geared
> towards the specific image types that my applications produced and consumed
> but
> it did allow me to do all the manipulations that I needed then and since. 
> These
> include the cropping of CCITT G4 images, rotations, conversion of ABIC to
> G4/JPEG and downsampling: all operations on IFD objects.
> 
> The point is that this entire effort was driven by the same motivation as
> that
> expressed by Harring.  The downside was being cut off from libtiff
> development
> and communal expertise, and being unable to contribute to the community with
> real code.  For example, I routinely deal with TIFF files around 300
> megabytes
> in size containing up to 14,000 images.  I have code to access random IFDs in
> constant time and it would be nice to contribute that to libtiff because I
> have
> seen many complaints about the unwieldy nature of large TIFF files.
> 
> If it turns out that my original assessment of libtiff was wrong then it is
> probably too late for me to turn back now but I'm not so proud that I mind
> discovering my error.  I've been known to make mistakes :-)
> 
> Anyway, in Harring's case I don't think he can be dealing with the TIFF input
> directly from a socket.  TIFF seems to demand a seekable input stream and
> unless
> there is something I don't know about sockets it would be difficult to
> implement
> a TIFF reader using one as a source.  TIFF output to a non-seekable stream
> *is*
> fairly straightforward.  In C++ terms you can say
> 	binary_stream << tiff;
> but not
> 	binary_stream >> tiff;
> 
> --
> Jon Saxton <js@triton.vg> OS/2 software developer
> U.S. agent for Triton Technologies International Ltd
> http://www.triton.vg/
> 
> 
> To subscribe or unsubscribe email tiff-request@olympiakos.com with subscribe
> or unsubscribe in the email body.  Libtiff home page: http://www.libtiff.org


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

To subscribe or unsubscribe email tiff-request@olympiakos.com with subscribe
or unsubscribe in the email body.  Libtiff home page: http://www.libtiff.org

