[sane-devel] Image Compression doesn't support in SANE protocal

Michael Hennebry hennebry at web.cs.ndsu.nodak.edu
Wed Aug 23 19:20:50 UTC 2006

On Wed, 23 Aug 2006, m. allan noah wrote:

> On Wed, 23 Aug 2006, Michael Hennebry wrote:
> > On Tue, 22 Aug 2006, m. allan noah wrote:
> >
> >> On Tue, 22 Aug 2006, René Rebe wrote:
> >>
> >>> Well that stinks as you lose a lot of detail with the lossy jpeg
> >>> decompression.
> >>
> >> even worse, if you are running the thing over the net backend, you convert
> >> to huge bitmap just before you transfer it over the network!
> >>
> >>>
> >>> Maybe let's add the JPEG frame type rather soon (even in SANE 1) and let's
> >>> add an IR (infra red) frame specification on the way as good film scanner
> >>> deliver for dust and the-like removal.
> >
> > Perhaps with carefully crafted code,
> > decompression compression could be made an identity operation.

i.e. compression(decompression(x))=x

> > If not, perhaps it could be made idempotent.

i.e  compression(decompression(compression(decompression(x))))=
> elaborate

The idea is to put a useful bound on the amount of damage
done by repeated decompressions and compressions.

The jpeg compression algorithms are not invertable.
For every jpeg compression algorithm, there are distinct X and  Y
such that compression(X)=compression(Y).
The same might be true for decompression, but I'm not sure.

> > If one is going to do compression, perhaps it would be good
> > to have a non-loosy method as one of the options.
> agreed. zlib ok?


Mike   hennebry at web.cs.ndsu.NoDak.edu
"it stands to reason that they weren't always called the ancients."
                                                      --  Daniel Jackson

More information about the sane-devel mailing list