51 lines
1.6 KiB
Plaintext
51 lines
1.6 KiB
Plaintext
From: kj7ny at email.com (kj7ny at email.com)
|
|
Date: Fri, 2 Apr 1999 23:57:14 -0800
|
|
Subject: TIFF, Python, and LibTiff
|
|
References: <6E5FB8BFB7CDD2118F6700A0C9E5871623B853@apexnews.rl.gov>
|
|
Message-ID: <7e4be9$ido$1@paperboy.owt.com>
|
|
Content-Length: 1322
|
|
X-UID: 564
|
|
|
|
Sorry about this post. I originally posted this message close to a year ago.
|
|
I have no idea where it came from again. I assume there was a server problem
|
|
on our end.
|
|
|
|
I took Guido's advise (way back then) and a just wrote my own TiffLib
|
|
module.
|
|
|
|
It works great and I couldn't have done it without Python!!!!!!!!!
|
|
|
|
The module not only creates Multi-Page Tiffs (MPT) out of Single-Page Tiffs
|
|
(SPT), but it has the ability to create what I call "Streaming Multi-Page
|
|
Tiffs".
|
|
|
|
The first version I wrote merely grabbed all of the SPT files, combined them
|
|
into a single MPT file, and stored it on magnetic. That took up too much
|
|
storage and was too limiting.
|
|
|
|
I rewrote it to have the option to stream the MPT back to the client without
|
|
storing a copy on magnetic.
|
|
|
|
The user can now select any range of pages (e.g. pages 50-60 out of 1037
|
|
pgs) to speed download and get just the pages they need. For some reason,
|
|
testing shows that the download time is consistently a few seconds faster if
|
|
the file is created on the fly than if it already existed and was just
|
|
downloaded (go figure?).
|
|
|
|
If you're curious, the application can be seen at
|
|
http://www2.hanford.gov/declass
|
|
|
|
You'd have to drill down through "Advanced Search" and find a document to
|
|
get to the streaming.
|
|
|
|
...couldn't have done it without Python!!!!...
|
|
|
|
Later,
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|