Image Compression doesn't support in SANE protocal

On Aug 22, 2006, at 2:51 PM, m. allan noah wrote:

> now that many low-end scanners support jpeg natively
(some ONLY do  
> jpeg!) i expect we will see more need for this.

Oh!

> as a short term fix, rather than adding a new
sane_frame type, the  
> backend can extract the compressed data, convert to raw
bitmap.  
> then frontend can convert to any compressed format it
wants. this  
> is not as efficient as keeping the compressed version
the entire  
> way through, but it works now.
>
> dell networked scanner backend works this way.

Well that stinks as you lose a lot of detail with the lossy
jpeg  
decompression.

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.

Yours,

-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Tue, 22 Aug 2006, René Rebe wrote:

>
> On Aug 22, 2006, at 2:51 PM, m. allan noah wrote:
>
>> now that many low-end scanners support jpeg
natively (some ONLY do jpeg!) i 
>> expect we will see more need for this.
>
> Oh!
>
>> as a short term fix, rather than adding a new
sane_frame type, the backend 
>> can extract the compressed data, convert to raw
bitmap. then frontend can 
>> convert to any compressed format it wants. this is
not as efficient as 
>> keeping the compressed version the entire way
through, but it works now.
>> 
>> dell networked scanner backend works this way.
>
> 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.

agreed. though i would think we would need to make a
well-known option 
like 'compression' or 'format' that such backends would
have to implement, 
with the default being 'bitmap'. these backends would then
'unjpeg' the 
files before passing to frontend, and existing frontends
will continue to 
work. then the user must manually set the option to
something other than 
'bitmap', if he knows his frontend supports this.

SANE2 could require that the frontend support jpeg, and that
could become 
the default for the 'format' option.

allan

>
> Yours,
>

-- 
"so don't tell us it can't be done, putting down
what you don't know.
money isn't our god, integrity will free our souls" -
Max Cavalera-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Tue, 2006-08-22 at 13:35 -0400, m. allan noah wrote:
> On Tue, 22 Aug 2006, René Rebe wrote:
> 
> >
> > On Aug 22, 2006, at 2:51 PM, m. allan noah wrote:
> >
> >> now that many low-end scanners support jpeg
natively (some ONLY do jpeg!) i 
> >> expect we will see more need for this.
> >
> > Oh!
> >
> >> as a short term fix, rather than adding a new
sane_frame type, the backend 
> >> can extract the compressed data, convert to
raw bitmap. then frontend can 
> >> convert to any compressed format it wants.
this is not as efficient as 
> >> keeping the compressed version the entire way
through, but it works now.
> >> 
> >> dell networked scanner backend works this way.
> >
> > 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.
> 
> agreed. though i would think we would need to make a
well-known option 
> like 'compression' or 'format' that such backends
would have to implement, 
> with the default being 'bitmap'. these backends would
then 'unjpeg' the 
> files before passing to frontend, and existing
frontends will continue to 
> work. then the user must manually set the option to
something other than 
> 'bitmap', if he knows his frontend supports this.
> 
> SANE2 could require that the frontend support jpeg, and
that could become 
> the default for the 'format' option.
> 
> allan
> 
> >
> > Yours,
> >
> 
Also for webcam devices the jpeg option is a welcome
feature, devices
like pac207 and sq930c/b support jpeg (and many other webcam
usb
bridges).
-- 
--------
m.vr.gr.
Gerard Klaver


-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

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.
If not, perhaps it could be made idempotent.

> SANE2 could require that the frontend support jpeg, and
that could become
> the default for the 'format' option.

Not having a default would better than making it a lossy
compression method.

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

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


-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

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.
> If not, perhaps it could be made idempotent.

elaborate

>
>> SANE2 could require that the frontend support jpeg,
and that could become
>> the default for the 'format' option.
>
> Not having a default would better than making it a
lossy compression method.
>
> 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?

allan

-- 
"so don't tell us it can't be done, putting down
what you don't know.
money isn't our god, integrity will free our souls" -
Max Cavalera-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

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))))=
                               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?

ok.

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


-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org