Your message dated Sun, 14 Jan 2024 15:44:21 +0100
with message-id <[email protected]>
and subject line Re: Bug#275893: pnmtopng: No way to specify scratch directory
has caused the Debian Bug report #275893,
regarding pnmtopng: No way to specify scratch directory
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
275893: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275893
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: netpbm
Version: 2:10.0-7
Severity: normal
Hi,
I am converting some large graphic files (100 to 600MB each) from tif to
pnm. I tried tiftopnm < foo.tif | pnmtopng > foo.png. However,
pnmtopng *insists* on writing huge files in /tmp. My /tmp is not very
big and cannot accomodate those files, and it refuses to store them in
places that can. I have tried commonly-used environment variable and
search manpages of the pnmtopng program and netpbm, but could find no
way to alter this behavior. It renders pnmtopng useless for me.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: alpha
Kernel: Linux 2.6.4-rc2
Locale: LANG=C, LC_CTYPE=C
Versions of packages netpbm depends on:
ii bc 1.06-15 The GNU bc arbitrary precision cal
ii libc6.1 2.3.2.ds1-17 GNU C Library: Shared libraries an
ii libjpeg62 6b-9 The Independent JPEG Group's JPEG
ii libnetpbm10 2:10.0-7 Shared libraries for netpbm
ii libpng12-0 1.2.5.0-7 PNG library - runtime
ii libtiff4 3.6.1-1.1 Tag Image File Format library
ii zlib1g 1:1.2.1.2-1 compression library - runtime
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 2:10.97.00-1
On 2004-10-10 John Goerzen <[email protected]> wrote:
> Package: netpbm
> Version: 2:10.0-7
> Severity: normal
> Hi,
> I am converting some large graphic files (100 to 600MB each) from tif to
> pnm. I tried tiftopnm < foo.tif | pnmtopng > foo.png. However,
> pnmtopng *insists* on writing huge files in /tmp. My /tmp is not very
> big and cannot accomodate those files, and it refuses to store them in
> places that can. I have tried commonly-used environment variable and
> search manpages of the pnmtopng program and netpbm, but could find no
> way to alter this behavior. It renders pnmtopng useless for me.
Hello John.
The head of converter/other/pnmtopng.c nowadays reads:
| A performance note: This program reads one row at a time because
| the whole image won't fit in memory always. When you realize that
| in a Netpbm xel array a one bit pixel can take 96 bits of memory,
| it's easy to see that an ordinary fax could deplete your virtual
| memory and even if it didn't, it might deplete your real memory and
| iterating through the array would cause thrashing. This program
| iterates through the image multiple times.
|
| So instead, we read the image into memory one row at a time, into a
| single row buffer. We use Netpbm's pm_openr_seekable() facility to
| access the file. That facility copies the file into a temporary
| file if it isn't seekable, so we always end up with a file that we
| can rewind and reread multiple times.
|
| This shouldn't cause I/O delays because the entire image ought to fit
| in the system's I/O cache (remember that the file is a lot smaller than
| the xel array you'd get by doing a pnm_readpnm() of it).
[...]
| Before May 2001, we did in fact read the whole image into an xel array,
| and we got complaints. Before April 2000, it wasn't as big a problem
| because xels were only 24 bits. Now they're 96.
And indeed in my tests the temporary file is small nowadays. (Its
location can be customized by setting TMPDIR et.al.) The
"before May 2001" is a little bit misleading in a Debian context since
Debian's netpbm was based on an older fork up until 2017.
cu Andreas
--- End Message ---
