>> I made a small change to the network protocol: the reply to the
>> START command now includes a member that specifies the byte order
>> of the image data (big or little-endian). This will be important
>> once there is a backend that supports depths greater than 8
>> bits/channel.
Andy> I am not sure, if you got my last comment about transferring
Andy> proprietary file formats.
I didn't. Was something wrong with your mailer or do you suspect
problems with the mailing list. In the latter case, I need to
investigate (the mailing list seems to work for me, as far as I can
tell).
Andy> There are some sources (digital
Andy> cameras in particular) that spit out fully featured JPGs even
Andy> with usefuls comments.
Andy> It would be no good idea quality-wise and due to the loss of
Andy> extra information to decompress->transfer->compress such
Andy> files.
Andy> I would suggest adding an extension to the start command
Andy> which says "I am transferring in proprietary format
Andy> $1. Suggested file-extension is $2."
Andy> This would allow for arbitrary files to be transferred
Andy> through SANE, though the backend would have to disable quite
Andy> a lot of its features which rely on being able to interpret
Andy> the data and simply suggest to save the file.
It's something we should keep in mind. It's a big change though and
I'd prefer to not incorporate it into the forthcoming SANE v1.0.
Transmitting black-box files isn't very useful, IMHO (what would GIMP
do with such a thing, for example?). With a bit of luck, something
like FlashPix will become standard. If that happens, we could add
direct support for such a format. That probably argues for building
up a frontend library of image conversion routines (the recent
discussions on image buffering point in the same direction).
--david
-- Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/ To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com