Hi Jürgen, Jürgen Mellinger writes:
> Hi Olaf, > > sorry for not being clear about my suggestion. I am aware that various > options exist for the user to select hardware gamma correction, and > that software gamma correction is discouraged. Sorry for not being clear that I only wanted to point out that there was already something in that area in the draft standard. > However, this is exactly the problem. Without software gamma > correction, a frontend is unable to request a certain gamma > correction, and cannot choose a gamma correction value suitable for > the current operating system, and the current device, or user > preferences transferred from a different device. So my suggestion > would be to prescribe a software gamma correction option with the > values 0 to 2.2, 0 standing for "off". Alternatively, a read-only > option "HardwareGamma" could provide the frontend with enough > information to implement software gamma correction by itself. 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.) 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 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. >> Am 13.10.2020 um 10:45 schrieb Olaf Meeuwissen <[email protected]>: >> >> Hi Jürgen, >> >> Jürgen Mellinger writes: >> >>> Specifying a gamma value for acquired scan data would greatly add to >>> usability as well. >> >> That's already in the version 2 draft. See >> >> https://sane-project.gitlab.io/standard/draft-2/api.html#gamma-table-options >> https://sane-project.gitlab.io/standard/draft-2/api.html#analog-gamma >> >> Both are for device-side gamma support and the standard discourages >> emulation in the backend of the former and forbids for the latter. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
