On 5/28/07, Oliver Rauch <Oliver.Rauch at rauch-domain.de> wrote: > Am Sonntag, den 27.05.2007, 14:08 -0400 schrieb m. allan noah: > > > > > > > > > > Well extending SANE1 will certainly start the new discussion > > > > about finishing SANE2 standard before starting - ACK ;) > > > > But as we did not move forward and scanner support for Linux > > > > is more or less stopped in its development, I vote for > > > > extending SANE1. > > > > > > > > As long as it won't hurt the API and the flow-control, introducing > > > > more frametypes should be no problem... > > > > > > Nice to see no big flamewar about the simple frametype addition :-)! > > It really is nice that no flamewar starts here but I do not support to > extend SANE1 this way. > > (see my following comment) > > > > > > SANE_FRAME_RGB, /* pixel-interleaved red/green/blue > > > > > bands */ > > > > > SANE_FRAME_RED, /* red band only */ > > > > > SANE_FRAME_GREEN, /* green band only */ > > > > > - SANE_FRAME_BLUE /* blue band only */ > > > > > + SANE_FRAME_BLUE, /* blue band only */ > > > > > + SANE_FRAME_INFRARED, /* infra-red band */ > > > > > + SANE_FRAME_RGBI, /* pixel-interleaved > > > > > red/green/blue/infra-red */ > > > > > + SANE_FRAME_JPEG /* Joint Photographic Experts Group's > > > > > JPEG */ > > > > > } > > > > > SANE_Frame; > > > > > > In the meantime I noticed the device can send Gray+IR as well which > > > would mean SANE_FRAME_GRAYI, as well. > > > > i know you probably get RGBIRGBI... from the scanner, but for > > backwards compatability and to avoid the proliferation of frametypes- > > i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add > > IR support to any other frametype by sending an extra frame, and > > existing frontends can be told to ignore the IR frame, and keep using > > the gray/rgb frames. > > Although you do not change the function calls > at the end you change the SANE API, a frontend that shall handle this > needs a lot of changes, also a backend needs a lot of changes. > > A new backend will not work properly with an old frontend.
yes- if a front-end does not have an else{} for unknown frametypes, then undesired results will occur. > I suggest to do all this in SANE2 because it is incompatible to SANE1. > In the moment a frontend has to handle 3 modes: > GRAY > RGB > RGB 3-pass > > With the new suggestions it would have to handle > GRAY > RGB > RGB 3pass > GRAY + INFRARED > RGB + INFRARED > RGB 3pass + INFRARED > RGBI > JPEG + INFRARED? > RED + INFRARED? > etc. i specifically want to avoid RGBI, so think of it this way- GRAY RGB RGB 3pass Anything + IR every frontend does not have to handle IR (some dont handle 3 pass rgb now), so: case default discard_frame(); where discard_frame() just reads til EOF on that frame, maybe with a warning on stderr. > The change of the transmission format hast been put into SANE2 > because it changes a lot in the comunication for frontends and backends. i disagree with 'a lot', but yes, it is a change. > Where is the advantage to put it into SANE1? > You will get incompatibilities between frontends and backends and you > slow down (if this is possible at all) the development of SANE2. It would be hard for sane2 development to get any slower :) The sane2 standard as of now, requires a fair number of changes to many places in both front and back-ends, and so it is very difficult to get started, and also very difficult to release anything with .2 soversion until the end. there is potentially a long wait before there are many backends or front-ends ported. > Finish the SANE2 standard. That solves all problems. i wish to see sane2 as well, but i do not believe that there are huge numbers of developers lurking on this mailing list, just waiting for us to get started on sane2. perhaps i am wrong, but i am not sure we have the critical mass required to start that project. allan -- "The truth is an offense, but not a sin"