RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Millican & Associates, Inc." <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Tue, 18 Oct 2005 17:01:06 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
John,

TIFF is kind of a funny "standard," because of it's non-standard use.  Since
the number of required fields is small, many applications do not support all
or even most of the optional fields.  The standard has options to include
many kinds of compression routines within the TIFF file.  For example, it
can use JPEG compression (which is just a method of compression -- like LZW
-- not a file format).  I don't know if the standard supports JPEG2000 (I
doubt it because it is new relative to TIFF), however, I agree that both
JPEG and JPEG2000 normally are *not* good options for scanned documents,
since they both are lossy and are optimized for photographs, not documents.
I also doubt that the standard supports DjVu compression, again because of
its relative newness.

You can establish custom tags to flag the compression routine(s) used, but
that defeats the purpose of having a single long-term standard, since any
new viewer/reader/editor will have to be modified to recognize the custom
tags (that's why many archival institutions require TIFFs to be submitted
uncompressed).  But if you're just looking at compression for transfer,
where once it's received it's decompressed then stored, you should be able
to implement any sort of lossless compression you want.  If you implement a
lossy compression (as DjVu allows, though does not necessarily require), you
really need to be aware of what you're losing.

Also, have you looked at your scanning application?  Many applications do
not automatically compress the file but compression might be available.  You
also could be suffering from "dirty" originals, which are faithfully
reproduced by the scanning process.  You could look at implementing
"thresholding" quality control, which reduces the extraneous image "noise"
and allows much better lossless compression on the resulting image.  That
way you know what you're losing first and can control it.

For more info about DjVu, check out http://www.djvuzone.org
(non-commerical).

Peter Lundell
Millican & Associates, Inc.

|-----Original Message-----
|From: Records Management Program
|[mailto:[log in to unmask]] On Behalf Of John Annunziello
|Sent: Tuesday, October 18, 2005 2:14 PM
|To: [log in to unmask]
|Subject: Compression software for EDRMS
|
|
|We have been scanning our records into our new EDRMS and
|finding that the files are of considerable size.  Does anyone
|know of a tool that is used at the scanning stage that will
|compress the files down in size when sending the images to our
|EDRMS.  Someone recommended JPEG2000, but it is my
|understanding that this is used for photo's or GIS type
|documents. We have been storing the documents as TIF's and
|want to continue storing them this way.  Any solutions?

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

ATOM RSS1 RSS2