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