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 ([email protected])
