Return-Path: <owner-tiff@olympiakos.com>
Received: from nataly.at1895.spb.edu (localhost [127.0.0.1])
	by at1895.spb.edu (8.12.4/8.12.4/Debian-4) with ESMTP id g7LHFAgL021624
	for <dron@at1895.spb.edu>; Wed, 21 Aug 2002 21:15:10 +0400
Received: from olympiakos.com (uucp@localhost)
	by nataly.at1895.spb.edu (8.12.4/8.12.4/Debian-4) with UUCP id g7LHFAsN021622
	for dron@at1895.spb.edu; Wed, 21 Aug 2002 21:15:10 +0400
Received: from knot.pu.ru (knot.pu.ru [193.124.85.214] (may be forged))
	by wg.pu.ru (8.9.1a/8.9.1) with ESMTP id QAA21012
	for <dron@at1895.spb.edu>; Wed, 21 Aug 2002 16:56:54 GMT
Received: from gate7.olympiakos.com (sdsl-64-32-199-150.dsl.iad.megapath.net [64.32.199.150])
	by knot.pu.ru (8.9.3/8.9.0) with ESMTP id UAA69757
	for <dron@at1895.spb.edu>; Wed, 21 Aug 2002 20:56:53 +0400 (MSD)
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id MAA32150;
	Wed, 21 Aug 2002 12:18:27 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Wed, 21 Aug 2002 12:09:51 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id MAA32078
	for tiff-outgoing; Wed, 21 Aug 2002 12:09:50 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from fuzzylog.simplesystems.org (fuzzylog.simplesystems.org [65.66.246.65])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id MAA32075
	for <tiff@olympiakos.com>; Wed, 21 Aug 2002 12:09:49 -0400
Received: from scooby.simplesystems.org (scooby.simplesystems.org [65.66.246.67])
	by fuzzylog.simplesystems.org (8.9.3/8.9.3) with ESMTP id LAA17268;
	Wed, 21 Aug 2002 11:05:38 -0500 (CDT)
Date: Wed, 21 Aug 2002 11:05:39 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
X-X-Sender: bfriesen@scooby.simplesystems.org
To: Rob van den Tillaart <rvdt@oce.nl>
cc: Peter Majer <majer@bitplane.com>, <tiff@olympiakos.com>
Subject: Re: OT: large memory allocation in Windows
In-Reply-To: <3D6399D5.EAA159DD@oce.nl>
Message-ID: <Pine.GSO.4.44.0208211056230.8371-100000@scooby.simplesystems.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-tiff@olympiakos.com
Precedence: bulk
Status: RO
Content-Length: 2231
Lines: 46

On Wed, 21 Aug 2002, Rob van den Tillaart wrote:

> Good point,
> Not all image manipulations would like this, e.g. convolutions
> which use simple pointer math to address neighbour pixels, all
> these routines would need to be rewritten. The speed would / could
> decrease, however this is the favorite solution direction.
> The rows do not need to be single pixel lines.
> The essence of your remark is do not keep it all in memory
> simultaneously.

This is a common solution.  All "serious" image processing packages
provide a means (e.g. "tiled" memory) to allow only a portion of the
image to be brought in at a time.

> >How about a memory mapped file? Could that possibly give you a
> >linear "pointer space" of 2GB or maybe even more? Of course the file would
> >not be completely mapped at all times, but maybe it would do the trick...
> >(Just a crazy idea. I don't know if it would work at all...).
>
> Used this years ago on some Sun1 Sparcstation with 8MB of memory.
> The C-calls were the "fseek, fread, fwrite" family, but disk is
> quite slow compared to on line memory. I recall a story of using memory on
> another Sparc over the network as this was faster than local disk
> access. OK, in those days everything was faster than a disk :)

ImageMagick (http://www.imagemagick.org) uses memory mapped files to
handle large images.  Using memory mapped files allows you to use
operations and functions which manipulate memory.  The MMU manages
caching of mapped pages so operations only cause disk I/O if a page
must be paged in or out. Using memory mapped files is no worse than
allowing your program's heap grow large enough that the system starts
paging.  The operation of the MMU and disk is the same.  The big
difference is that you have programmatic control over what gets mapped
to the address space and the size of the address space, whereas with
everything on the heap, you have no control and the system may thrash.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen


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

