[sane-devel] Sane API

[Alexander Pevzner]

Hi Olaf,

On 10/14/20 1:56 PM, Olaf Meeuwissen wrote:
> I guess what you as a user really want is a frontend giving you an
> option to set a gamma correction some way.  Single value for RGB, maybe
> three values for R, G and B each or even hand-crafted profiles.  What
> you as a frontend implementer really want is
> 
>   - a way to tell the backend to not muck with gamma at all and do
>     everything in software yourself, or
>   - a way to pass those settings to the backend and let that figure out
>     the best way to achieve what it's been asked to do (maybe with a hint
>     as to what constitutes best, e.g. speed, memory, image quality, etc.)

 From another hand, draft 2.0 standard dictates a particular order of 
applying image enhancement filters and requires that if hardware applies 
these filters a different way, backend should perform a compensation.

This is good by itself (we are trying to achieve a similar behavior on 
all devices), but what is the practical difference between 
software-simulated gamma correction and hardware-implemented gamma 
correction plus software compensation in backend? I bet also, that 
"universal" backends, like BJNP/PIXMA, ESCL, WSD, have no idea how gamma 
compensation is implemented by the particular device.

And another thing, if we are still speaking about gamma correction, I 
cannot imagine a physical process within a device that can perform the 
gamma correction. In any case, it will be performed by some piece of 
software, either by firmware or at the host side. And taking into 
account that table-driven gamma correction is a trivial thing, there is 
no practical difference between the place where it is performed, even in 
a terms of CPU load and memory usage. Here the gamma correction is 
different from, for example, brightness; brightness control can be 
implemented by setting the particular lightening level.

And yes, the end user wants gamma to be implemented somehow. So if 
backend implements gamma in software, while frontend doesn't, end user 
wins, if backend doesn't implement gamma just because it is prohibited 
by specification, and frontend doesn't implement it too, end user looses 
the gamma correction.

 From another hand, I understand a requirement from frontend developers, 
to understand, what actually goes on. Though honestly speaking, there 
are currently no widely used frontends that care.

So may be, instead of prohibiting of software implementation of 
particular options, we will define a set of read-only "advanced" 
options, that will allow inquisitive frontend to explicitly query, how 
particular option is implemented, with values of 
"hardware"/"software"/"compensated", for example.

> The real problem with these settings that may or may not be supported by
> hardware is deciding and informing everything involved about who's
> responsible for doing what.  I've seen similar issues in CUPS filter
> chains where, for example, 2-up and 90 degree rotation settings would be
> applied by multiple filters so in a pretty bad case you'd end up with a
> page that's 8-up and rotated by 270 degrees :-o

 From another hand, from the user perspective, it is better, if image 
will be rotated 9 times that if image cannot be rotated at all :-)

> The SANE backends are very much like a filter between the device and
> your frontend.  There was also talk about "middleware" and if that
> enters the picture you really need to make sure who's going to take
> responsibility for what so that what arrives at the frontend is the way
> it's supposed to be.

Yes, the ideal place to "harmonize" things would be a some kind of 
middleware between backends and frontends. But we have what we have...

-- 

	Wishes, Alexander Pevzner (pzz at apevzner.com)