[sane-devel] test backend: 1 bit RGB data for grid pattern
dav...@mostang.com said: > Never mind my comments. I missed the fact that you're talking about > 1-bit RGB data only (not 1-bit monochrome, which does make a lot of > sense). I think I added 1-bit RGB just because the Mustek scanner > could do it, but it always was a mystery to me why 1-bit RGB data > would be useful. I don't think even dithering helps there. Hum, I would have thought that it was obvious. It can be handy in the production of a one bit monochrome image, where you don't know in advance whether averaging RGB,RG,GB,RB or just selecting one of R,G,B will produce the best monochrome scan of a colour image. Well more likely text on a colour background, or coloured text, or even a mixture of the two. All that said, I suspect that the number of people actually making use of this is rather small. JAB. -- Jonathan A. Buzzard Email: jonat...@buzzard.org.uk Northumberland, United Kingdom. Tel: +44(0)1661-832195
[sane-devel] test backend: 1 bit RGB data for grid pattern
Oliver Schwartz wrote: > Hi, > > On Wednesday 25 September 2002 21:05, Henning Meier-Geinitz wrote: > >>Hi, >> >>On Wed, Sep 25, 2002 at 11:16:15AM -0700, David Mosberger-Tang wrote: >> >>> Oliver> I think that makes sense. When a backend really does >>> Oliver> support this then it can send it as 8 bit rgb image. >>> >>>Do we know for a fact that there are no high-speed devices out there >>>that produce, say, dithered 1-bit data? If not, inflating the storage >>>and bandwidth requirements for such devices by a factor of 8 seems >>>like a non-trivial issue. >> >>The older Mustek SCSI scanners could send 1 bit per color RGB so there >>are devices that can. > > > The Snapscan scanners also support 1 bit per color. You can even send your > own > dither matrix to the scanner. (In theory, that is. I never quite got it to > work.) However, the backend will expand the data to 8 bit/color, so original > problem does not appear in the snapscan backend. Same with Sharp scanners and the Sharp backend. The scanners can produce 1 bit/sample RGB data, but the backend expands that to 8 bit/sample, because [x]scanimage did not write useful output files, at least at the time, when I implemented the 1 bit mode. Abel
[sane-devel] test backend: 1 bit RGB data for grid pattern
Hi, On Wednesday 25 September 2002 21:05, Henning Meier-Geinitz wrote: > Hi, > > On Wed, Sep 25, 2002 at 11:16:15AM -0700, David Mosberger-Tang wrote: > > Oliver> I think that makes sense. When a backend really does > > Oliver> support this then it can send it as 8 bit rgb image. > > > > Do we know for a fact that there are no high-speed devices out there > > that produce, say, dithered 1-bit data? If not, inflating the storag= e > > and bandwidth requirements for such devices by a factor of 8 seems > > like a non-trivial issue. > > The older Mustek SCSI scanners could send 1 bit per color RGB so there > are devices that can.=20 The Snapscan scanners also support 1 bit per color. You can even send you= r own=20 dither matrix to the scanner. (In theory, that is. I never quite got it t= o=20 work.) However, the backend will expand the data to 8 bit/color, so origi= nal=20 problem does not appear in the snapscan backend. > But I have never seen the benefit. I mean, 2 > "colors", black and white are ok. 256 (or more) also. But 8? Ok, > that's like CGA (?). > > What to do with these images? I mean, it's RGB so it can't be "lineart > + some IR stuff". IMHO it only makes sense if the scanner does some sort of dithering. The=20 dithered image may be send to a raster printer directly. This will save y= ou=20 the conversion / dithering on the host PC. In such a case, 1 bit/colour m= ay=20 make sense. Regards, Oliver
[sane-devel] test backend: 1 bit RGB data for grid pattern
Hi, On Wed, Sep 25, 2002 at 11:16:15AM -0700, David Mosberger-Tang wrote: > Oliver> I think that makes sense. When a backend really does > Oliver> support this then it can send it as 8 bit rgb image. > > Do we know for a fact that there are no high-speed devices out there > that produce, say, dithered 1-bit data? If not, inflating the storage > and bandwidth requirements for such devices by a factor of 8 seems > like a non-trivial issue. The older Mustek SCSI scanners could send 1 bit per color RGB so there are devices that can. But I have never seen the benefit. I mean, 2 "colors", black and white are ok. 256 (or more) also. But 8? Ok, that's like CGA (?). What to do with these images? I mean, it's RGB so it can't be "lineart + some IR stuff". On the other hand, if we exactly define these modes nobody is hurt even if they are never used. Bye, Henning
[sane-devel] test backend: 1 bit RGB data for grid pattern
abel deuring schrieb: > > Henning Meier-Geinitz wrote: > > > > The easiest way would be to > > forbid 1 bit RGB in the standard :-) > > that would indeed be a convenient alternative. I think that makes sense. When a backend really does support this then it can send it as 8 bit rgb image. Bye Oliver -- Homepage: http://www.rauch-domain.de sane-umax: http://www.rauch-domain.de/sane-umax xsane: http://www.xsane.org E-Mail: mailto:oliver.ra...@rauch-domain.de
[sane-devel] test backend: 1 bit RGB data for grid pattern
Henning Meier-Geinitz wrote: > > Hi, > > On Tue, Sep 24, 2002 at 11:58:41PM +0200, abel deuring wrote: > > while playing with the test backend, I noticed that the "scan data" > > produced for the grid pattern in 1 bit RGB mode differs from the output > > for 1 bit grayscale mode. The data for gray scale mode is like: > > Argh, I hate this 1-Bit RGB mode. Nobody needs it and it provides that > many opportunities to make mistakes. Bit-order, meaning of 1 and 0, > byte-interleaved versus bit-interleaved. The easiest way would be to > forbid 1 bit RGB in the standard :-) that would indeed be a convenient alternative. > > > > > ... 00 00 00 0f ff ff ff f0 00 00 00 ... > > > > while the data for 1 bit RGB mode is: > > > > ... 00 00 00 f0 ff ff ff 0f 00 00 00 ... > > > > (where one number in the line above means actually "means" three bytes > > for the three colors.) > > If I remember correctly, I made the difference in bit-order > intentionally. The reason was simple: that's the way it was > implemented in xscanimage. And that's the only definition I found. I > think there was some discussion on the list about this but we camr to > no conclusion. Probably because nobody really needed that mode :-) > > > I'm too tired to check the Sane API doc, instead a question: Am I right > > that this is a bug, or do we have different bit orders for 1 bit gray > > and RGB mode ? > > It's not logical, you are right. As far as I understsand, the SANE > standard does NOT state how the bit-order for 1 Bit modes is. There is > an image for 8-bit modes that could be interpreted like "bit 7 is the > first pixel" but it's not written explicitely. That's also the order > used in pbm files. The confusion is the reason why I have added an > entry "Add some text about the meaning of bits in 1-bit modes." to the > TODO list. > > > I don't think so; the fix would be to change line 173 in test-picture.c > > from: > > > > SANE_Word xfull = x * 8 / 3 + x1; > > > > to: > > > > SANE_Word xfull = x * 8 / 3 + (7 - x1); > > Ok. But then we should at least also change xscanimage. If I remember > correctly, quiteinsane was also able to display these modes. Xsane > doesn't like them at least when using the preview which is ok. > However, it prints that it can't display 16 bits/color :-) I think that I'll put either some #ifdefs into the sources of PIL.sane to enable/disable/configure the processing of 1 bit RGB data, or I'll use some flags which allow run time configuration. Since we will hopefully work on/with Sane version in the near future, there is no point to argue about less-than-well-defined things in Sane 1. Abel
[sane-devel] test backend: 1 bit RGB data for grid pattern
> On Wed, 25 Sep 2002 20:12:27 +0200, Oliver Rauch > said: Oliver> abel deuring schrieb: >> Henning Meier-Geinitz wrote: >> > >> > The easiest way would be to > forbid 1 bit RGB in the standard >> :-) >> that would indeed be a convenient alternative. Oliver> I think that makes sense. When a backend really does Oliver> support this then it can send it as 8 bit rgb image. Never mind my comments. I missed the fact that you're talking about 1-bit RGB data only (not 1-bit monochrome, which does make a lot of sense). I think I added 1-bit RGB just because the Mustek scanner could do it, but it always was a mystery to me why 1-bit RGB data would be useful. I don't think even dithering helps there. --david
[sane-devel] test backend: 1 bit RGB data for grid pattern
> On Wed, 25 Sep 2002 20:12:27 +0200, Oliver Rauch > said: Oliver> abel deuring schrieb: >> Henning Meier-Geinitz wrote: >> > >> > The easiest way would be to > forbid 1 bit RGB in the standard >> :-) >> >> that would indeed be a convenient alternative. Oliver> I think that makes sense. When a backend really does Oliver> support this then it can send it as 8 bit rgb image. Do we know for a fact that there are no high-speed devices out there that produce, say, dithered 1-bit data? If not, inflating the storage and bandwidth requirements for such devices by a factor of 8 seems like a non-trivial issue. --david
[sane-devel] test backend: 1 bit RGB data for grid pattern
Hi, On Tue, Sep 24, 2002 at 11:58:41PM +0200, abel deuring wrote: > while playing with the test backend, I noticed that the "scan data" > produced for the grid pattern in 1 bit RGB mode differs from the output > for 1 bit grayscale mode. The data for gray scale mode is like: Argh, I hate this 1-Bit RGB mode. Nobody needs it and it provides that many opportunities to make mistakes. Bit-order, meaning of 1 and 0, byte-interleaved versus bit-interleaved. The easiest way would be to forbid 1 bit RGB in the standard :-) > > ... 00 00 00 0f ff ff ff f0 00 00 00 ... > > while the data for 1 bit RGB mode is: > > ... 00 00 00 f0 ff ff ff 0f 00 00 00 ... > > (where one number in the line above means actually "means" three bytes > for the three colors.) If I remember correctly, I made the difference in bit-order intentionally. The reason was simple: that's the way it was implemented in xscanimage. And that's the only definition I found. I think there was some discussion on the list about this but we camr to no conclusion. Probably because nobody really needed that mode :-) > I'm too tired to check the Sane API doc, instead a question: Am I right > that this is a bug, or do we have different bit orders for 1 bit gray > and RGB mode ? It's not logical, you are right. As far as I understsand, the SANE standard does NOT state how the bit-order for 1 Bit modes is. There is an image for 8-bit modes that could be interpreted like "bit 7 is the first pixel" but it's not written explicitely. That's also the order used in pbm files. The confusion is the reason why I have added an entry "Add some text about the meaning of bits in 1-bit modes." to the TODO list. > I don't think so; the fix would be to change line 173 in test-picture.c > from: > > SANE_Word xfull = x * 8 / 3 + x1; > > to: > > SANE_Word xfull = x * 8 / 3 + (7 - x1); Ok. But then we should at least also change xscanimage. If I remember correctly, quiteinsane was also able to display these modes. Xsane doesn't like them at least when using the preview which is ok. However, it prints that it can't display 16 bits/color :-) Bye, Henning
[sane-devel] test backend: 1 bit RGB data for grid pattern
Hi all, while playing with the test backend, I noticed that the "scan data" produced for the grid pattern in 1 bit RGB mode differs from the output for 1 bit grayscale mode. The data for gray scale mode is like: ... 00 00 00 0f ff ff ff f0 00 00 00 ... while the data for 1 bit RGB mode is: ... 00 00 00 f0 ff ff ff 0f 00 00 00 ... (where one number in the line above means actually "means" three bytes for the three colors.) I'm too tired to check the Sane API doc, instead a question: Am I right that this is a bug, or do we have different bit orders for 1 bit gray and RGB mode ? I don't think so; the fix would be to change line 173 in test-picture.c from: SANE_Word xfull = x * 8 / 3 + x1; to: SANE_Word xfull = x * 8 / 3 + (7 - x1); Abel
