> If you don't have any technical reasons (and "I think Infrared is a lot
> like Alpha" isn't a technical reason) for removing this frame format,
> which IS ALREADY IN USE then please put it back. The fact that saving
> RGBI->RGBA might not be faithful is not helped by renaming RGBI.
>
Hi Nick,
if something is already in use or not is not relevant!
IT IS NOT DEFINED IN THE SANE STANDARD,
WHAT WE HAVE IS A HACK AND NOTHING ELSE!
If it is stupid to save an RGB+infrared as RGBA then you must tell
how to save this format. Ok, I can copy it to /dev/null, but I don`t think
this is what you want.
If we save it as red,green,blue,infrared than it is the same format the
scanner sends, so the SANE_FRAME_RAW would do exactly the same
you want. If you do not define a image-file format for this, we can do
it only this way!
> I see no sign of "thousands of SANE_FRAME_WHATEVER" -- Come back with
> this doom-laden message when we have even TEN such frame types.
It is not good to add one format that does not make sense. So we should not wait
until
we have 5 bad formats.
I don`t say that we should not add SANE_FRAME_INFRARED or RGBI.
I only say it does not make any sense if we do not define how to save and handle
them.
As long as there is no file format for RGBIr and another one for RGBUv
and we have to handle it the same way and ony the user knows the difference,
why should we add two different formats for this.
We add SANE_FRAME_RAW and the user has to give the file a name that
tells him what is in the file.
> I can't see a use for SANE_FRAME_RAW -- If I receive a SANE_FRAME_RAW I
> am now the proud owner of some random bytes. The contents are totally
> undefined, so why use SANE at all?
That is exact what I say but you did not answer my question until now:
HOW SHALL A FRONTEND HANDLE THE RGBI FORMAT?
I make the opposite suggestions:
1) A frontend knows how to handle an alpha channel, so we should add it as
a sane frame format.
2) If you want to send data to the frontend and you do not say how to display
it,
we only can handle it as raw data. This does make sense because you may
want to work with this data with your own software but you need a program
to get this data from the scanner/image generating device.
> SANE_FRAME_CMYK would be useful only if someone made a device which
> exports such data. I'm not aware of any such devices.
If someone needs it, we can add this without any problems because we know how
a frontend has to handle it!
>
>
> SANE_FRAME_JPEG is useful, and was proposed (in some form) for SANE 2.0
> Since we now have someone on the list who wants to export this kind of
> frame, we should try to see what can be done to accomodate it ASAP.
Ok, lets add it, where is the problem?
Bye
Oliver
-- EMAIL: Oliver.Rauch@Wolfsburg.DE WWW: http://www.wolfsburg.de/~rauch
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com