>> The feature you describe (an additional toggle setting for
>> stretch vs truncate) seems excessive even for Advanced options,
>> where it will probably confuse users in a less technical
>> environment. I don't think we want the advanced setting to mean
>> "Deep magic for image processing people".
Jonathan> Throw hands up in air, so SANE is not for use by image
Jonathan> processing people then.
Such statements are not particularly helpful. Particularly not if
they're half-truths. Let's see if we can determine what the real
issue is:
(a) loss of precision due to 12 bit->16 bit conversion
(b) increase of memory size and/or transmission time due to
the absence of a 12 bit packed format
As others have pointed out, (a) is not an issue. Even when doing the
scaling as proposed in an earlier mail, no precision whatsoever is
lost. You can always convert back to the original bits if necessary.
If you're proposing to extend SANE so the backend can tell the
frontend what the actual precision is, that's something we can talk
about.
I can see that (b) may be an issue as not supporting a 12 bit packed
format does increase the size of an image by 33%. However, note that
this is an issue only for the frontend to backend channel. How the
image gets saved and/or manipulated in the frontend is entirely up to
the frontend. As per your own suggestion, your application is doing
the math in 16 bit anyhow, so space does not really seem to be the
issue here.
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com