Hello Ullrich. It is not your scanner that needs the gamma value of 1.6, it is the screen/monitor you use to view the image. And this is more or less the same for all scanners and backends.
When you use the original windows driver or especially a professional scanning tool then you have to apply a gamma value of about 1.6 to 2.3, that depends in first order of the screen/monitor. You don`t need to do anything with the gamma value in xsane. Disable the automatic gamma selection in the preferences/setup enhancement tab and select the gamma value 1.6 in the xsane main window and store it as device preferences. You never need to touch it again when you want it always to be 1.6 There is no problem when you define a startup gamma table with a gamma value of 1.6. But when the frontend loads its own gamma table to the backend/scanner then this table should not be modified and when it is a linear gamma table (gamma=1.0), then the scanner/backend should output a in image with a gamma value=1.0 and not 1.6 But in general I think it still has a bad side effect when you define a startup gamma table of 1.6. When your and other backends do this then there is no need for the authors of the "stupid" frontends to improve such things and you will never get better frontends. A workaround like this may sound like a good idea at first but when you look some time into the future then the result of the workaround is that things are more worse than if you do not apply this workaround. I suggest to spend the time to tell the frontend authors what they should do (apply a startup gamma table of 1.6 or give the user a better chance to enter an own gamma value in an easy way). BTW: The gamma table does not effect the analog electronics, it is nothing else then a lookup table, the same table that is used by xsane. There are scanners with analog gamma correction functions, but these functions do not use a gamma table, they use a gamma value that effects the nonlinear amplification of the analogue parts of the scanner. Oliver Am Fre, 2004-09-03 um 16.59 schrieb Ullrich Sigwanz: > Hmm, > > I think I am a bit in a dilemma now. > > Maybe it is because the niash scanner require a gamma <> 1.0. > But correcting this on backend-level is not appropriate. > > I think it is mainly because different frontends behave differently. > > When I have a certain startup-Gamma, > > StarOffice/OpenOffice, > kooka, > xscanimage, > (I am not quite sure about QuiteInSane) > > keep this value and produce "perfect" scans without any additional biasing > right from the beginning. > XSane is the only frontend, that I know (which does not need to have > any relevant meaning), that changes the gamma table before a Preview is > done! > > Is it possible to "tell" XSane somehow, which is the recommended Gamma? > Or other way round... > > The original Gamma table sent to the Scanner, > effects the analog electronics in a way that the received data > is in the most "biased" format. > > So it seems a bit artificial for me (but may be I am wrong) when > a worse analog data format is chosen and is then extrapolated to a format, > which would already have been the best one before. > > When it is possible to convert data from Gamma=1.0 to Gamma=1.6 > by software, the other way should also work, shouldn't it? > > You see, the startup gamma table is "best", and there is no need to change > it > unless you want to achieve certain effects, which I do not dare to judge > concerning their benefit. > When I first worked with XSane, I was always confused, why my previews were > so dark. Having to change the gamma back to a value that lets the preview > look reasonable, is a bit clumsy, especially when you have to do many scans. > > But... Please, do not understand me wrong. > > I highly appreciate your application and XSane is my favorite scanning front > end. > Nevertheless there seems to be a small potential of improvement. > > So I am not sure what to do, I have to admit. > Maybe you can help me out? > > Greetings > and have a nice weekend > > Ullrich > > > >
