[sane-devel] test backend: 1 bit RGB data for grid pattern

[abel deuring]

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