[sane-devel] Re: Affordable film scanner supported by SANE

Henning Meier-Geinitz henning@meier-geinitz.de
Fri, 21 Mar 2003 16:34:47 +0100


Hi,

On Wed, Mar 19, 2003 at 08:44:51PM +0000, Major A wrote:
> > Can you give some details what has to be done for that? Are changes
> > necessary for the backends, frontends and/or the API?
> 
> I don't think much has been done yet. I don't think we need to change
> any backends (the only thing would be if backends wanted to supply
> their own ICC profiles, for which a new API function would be ideal).

Wouldn't it be possible to use any of the existing SANE option types
for the icc profile? If I understand correctly, it's a read-only
option which is even static during runtime. If this is not possible,
better create a new option type instead of yet another sane api call.
How big are icc profiles usually?

> The rest is not that simple... ICC profiles work by applying a LUT to
> each channel, then transforming with a matrix, and finally applying
> another set of LUTs. This can all be done in the frontend, but it
> would be possible to optimize things a bit:

LUT = gamma table?

> 1. The first LUTs can be done in hardware by the scanner. This makes
>    sense because most of the time they serve the purpose of
>    linearizing the incoming data in terms of perceived colour -- that
>    means, we could probably afford to only obtain 8-bit data from the
>    scanner, which would speed up scanning.

If the scanner can do that at all. But what does that mean for us? The
backend provides the icc profile and the frondend decides how to set
up the gamma tables to get a linear output?

> 2. Exposure can be incorporated into the first LUT. This would avoid a
>    LUT that discards the top (bright) end of the scale, therefore not
>    making ideal use of the CCD's noise performance.

What is exposure exactly? Exposure time? I'm asking because at least
some of my scanners don't provide an option to set that. Only "gain"
and "offset".

> Both would require changes to the frontend only, but for 2., we would
> have to add well-known options to the SANE standard.

Proposals are welcome. But it must be made pretty clear how to
interpret the option and what it's value means.

> As of programming, there are basically two choices if you want an
> open-source colour management system: lcms (which seems to have
> evolved into a standard library, it's part of Debian as well), and
> gcms, which nobody seems to actively use. The advantage of the latter
> is that the developer is on this list (me that is).
> 
> To summarize, I think these changes are necessary:
> 
> 1. new API function(s) for providing ICC profile data through the SANE
>    protocol. This would be good because then a backend would have
>    access to its own profiles and supply them to any frontend, even it
>    the frontend runs on a different computer.
> 
> 2. incorporate ICC-based transforms into the frontend(s), along with
>    options to store scans in a variety of colour spaces (XYZ and Lab
>    as well as sRGB, Adobe RGB, etc.)
> 
> 3. optionally, define new standard options for exposure, which can be
>    used (optionally) by the frontend
> 
> 4. ideally, we also want a (SANE-independent) tool for creating
>    profiles based on scans from calibrated targets.
> 
> Hope this makes sense,

Well, you seem to be the expert, so go ahead :-)

Bye,
  Henning