> I just want to tell it: Here come 4 channels, the first 3 are
> RGB (which you may use for preview or other stuff)
> and the last one is something I want to be able to save
> as alpha channel to png or to gimp.
Ok, this would make sense for someone who is experimenting with
SANE.
> I have no objections to add
> SANE_FRAME_G3
> SANE_FRAME_G4
> SANE_FRAME_JFIF
> SANE_FRAME_RGBI
> SANE_FRAME_TEXT
> and anything you want , but I would like to see at least:
> SANE_FRAME_RAW
> SANE_FRAME_RGBA
> too.
Ok, I have no problems to the last two but I feel they should be
avoided in widespread production code. I.e, they should be more
intended for experimenting and custom modifications.
> Right now the only link of the 4th channel of a Coolscan scanned
> image to "infrared" is that it has been scanned with an infrared LED as light
> source. After that I'm doing all kinds of transformation on it
> which mix R,G,B and I (and I will do even more in the future)
> to make it show only the dust in the image, and not the
> color information. That is to say: when you get the 4th channel
> out of the backend it is no longer an "infrared" image but a
> "dust" image, so we might as well define SANE_FRAME_RGBD(ust).
I hope it can still output the pure RGBI as well.
Just curious, but why would your production code do the 4x4 color
transform in the backend, and the defect interpolation elsewhere?
It would seem more logical to do it in the same place.
As more manufacturers will take a licence on Digital ICE, we can
expect more scanners that have an IR channel. Therefore, at some point
in time, it will make sense to do the defect removal in the frontend
instead of in all the backends and a SANE_FRAME_RGBI will be essential.
-- -- Ewald
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com