[sane-devel] API addition request
Hello all, Regarding the need for ICC profile support with SANE, I would like to suggest an API addition in the form of a SANE_CAP_COLOUR capability flag. This may not solve the problem as a whole, but it is enough for the gsoc project with locally attached scanner and also would be needed anyway in the long run. Allan suggested this already on the ICC support for SANE thread. I'm attaching an example patch for the pnm backend, so that $ scanimage --help -d pnm would also print out a hint that an option affects colour output. In respect to updating the backends, this flag is optional, so backends that will use it will have color management support, others won't. So, what do you think? Thank's Yiannis -- next part -- A non-text attachment was scrubbed... Name: sane_color_cap_flag.diff Type: text/x-patch Size: 4044 bytes Desc: not available URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/ddbba567/attachment-0001.bin
[sane-devel] (no subject)
An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/1a0eed0c/attachment.htm
[sane-devel] API addition request
While we are at it, It would make my life easier if there were something to indicate whether the scan is from the flatbed or ADF, and if the latter, whether duplex or not. Regards Jeff
[sane-devel] API addition request
On Sat, 20 Jun 2009 12:29:55 +0200 Jeffrey Ratcliffe jeffrey.ratcliffe at gmail.com wrote: While we are at it, It would make my life easier if there were something to indicate whether the scan is from the flatbed or ADF, and if the latter, whether duplex or not. agreed. should be easy too. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] API addition request
On Sat, 20 Jun 2009 14:18:00 +0200
Alessandro Zummo azummo-lists at towertech.it wrote:
While we are at it, It would make my life easier if there were
something to indicate whether the scan is from the flatbed or ADF, and
if the latter, whether duplex or not.
agreed. should be easy too.
We could grow SANE_Parameter with a flags field and a version field:
typedef struct
{
SANE_Int version;
SANE_Word flags;
SANE_Frame format;
SANE_Bool last_frame;
SANE_Int bytes_per_line;
SANE_Int pixels_per_line;
SANE_Int lines;
SANE_Int depth;
}
SANE_Parameters;
#define SANE_PARAMF_DUPLEX (1L 0)
#define SANE_PARAMF_ADF (1L 1)
We could also add a media type field, with values
like paper, film negative, film positive, .
Having a version field allows to extend it without
breaking compatibility.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
[sane-devel] API addition request
On Sat, Jun 20, 2009 at 8:42 AM, Alessandro Zummo azummo-lists at towertech.it
wrote:
On Sat, 20 Jun 2009 14:18:00 +0200
Alessandro Zummo azummo-lists at towertech.it wrote:
While we are at it, It would make my life easier if there were
something to indicate whether the scan is from the flatbed or ADF, and
if the latter, whether duplex or not.
agreed. should be easy too.
We could grow SANE_Parameter with a flags field and a version field:
typedef struct
{
SANE_Int version;
SANE_Word flags;
SANE_Frame format;
SANE_Bool last_frame;
SANE_Int bytes_per_line;
SANE_Int pixels_per_line;
SANE_Int lines;
SANE_Int depth;
}
SANE_Parameters;
#define SANE_PARAMF_DUPLEX (1L 0)
#define SANE_PARAMF_ADF (1L 1)
We could also add a media type field, with values
like paper, film negative, film positive, .
Having a version field allows to extend it without
breaking compatibility.
We could do that, but then any front-end that uses sane would have to check
the backend version number and the params version number. I would be more
inclined to convert 'last_frame' to 'flags', then you can probably get by
without changing existing backends (other than a word substitution).
But, back to Jeffrey's request- is it enough to know ADF or not and Duplex
or not in the params struct, or do you need to know that sooner? Also, it
would be good to know which side of the duplex scan this is...
allan
--
The truth is an offense, but not a sin
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/d2d8551c/attachment.htm
[sane-devel] API addition request
On Sat, Jun 20, 2009 at 9:49 AM, Alessandro Zummo azummo-lists at towertech.it wrote: On Sat, 20 Jun 2009 09:38:24 -0400 m. allan noah kitno455 at gmail.com wrote: We could do that, but then any front-end that uses sane would have to check the backend version number and the params version number. I would be more inclined to convert 'last_frame' to 'flags', then you can probably get by without changing existing backends (other than a word substitution). If we have decided to break for sane 2, it might be worthwhile to do that in such a way to avoid troubles in the future. but this does not avoid troubles, it just pushes them out to the front-end developer, forcing him to have multiple branches in his code to deal with all the variations. I would much prefer to have the major number of the backend be a contract with the front-end author. If that means we have to leave some unmaintained backends behind, so be it. allan -- The truth is an offense, but not a sin -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/19480aa0/attachment.htm
[sane-devel] API addition request
On Sat, 20 Jun 2009 09:58:03 -0400 m. allan noah kitno455 at gmail.com wrote: If we have decided to break for sane 2, it might be worthwhile to do that in such a way to avoid troubles in the future. but this does not avoid troubles, it just pushes them out to the front-end developer, forcing him to have multiple branches in his code to deal with all the variations. I would much prefer to have the major number of the backend be a contract with the front-end author. If that means we have to leave some unmaintained backends behind, so be it. So you force it to either switch or to maintain two trees. Oh well, I do not agree, but.. so be it. I'd love to have the media type anyway ;) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] API addition request
On Sat, Jun 20, 2009 at 10:14 AM, Alessandro Zummoazummo-lists at towertech.it wrote: On Sat, 20 Jun 2009 09:58:03 -0400 m. allan noah kitno455 at gmail.com wrote: ?If we have decided to break for sane 2, it might be worthwhile ?to do that in such a way to avoid troubles in the future. but this does not avoid troubles, it just pushes them out to the front-end developer, forcing him to have multiple branches in his code to deal with all the variations. I would much prefer to have the major number of the backend be a contract with the front-end author. If that means we have to leave some unmaintained backends behind, so be it. ?So you force it to either switch or to maintain two trees. Julien's idea is precisely not to maintain two trees, but rather to abandon ancient code. Every other project I have ever been involved with has some mechanism to remove old stuff. Sane should be no different. ?Oh well, I do not agree, but.. so be it. ?I'd love to have the media type anyway ;) And you can get it, along with things that other people want, as long as we are realistic about our capabilites, and we keep the front-end author's job as easy as possible. allan -- The truth is an offense, but not a sin
[sane-devel] API addition request
On Sat, 20 Jun 2009 12:54:44 -0400 m. allan noah kitno455 at gmail.com wrote: ?So you force it to either switch or to maintain two trees. Julien's idea is precisely not to maintain two trees, but rather to abandon ancient code. Every other project I have ever been involved with has some mechanism to remove old stuff. Sane should be no different. The problem with SANE is that you might loose support for hardware which is still in use. Most projects do not carry on hw driver and those who do and followed the path you suggested (i.e. ati and nvidia graphics drivers)... well.. let's just say that the users did not appreciate. ?Oh well, I do not agree, but.. so be it. ?I'd love to have the media type anyway ;) And you can get it, along with things that other people want, as long as we are realistic about our capabilites, and we keep the front-end author's job as easy as possible. nic, thanks ;) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] API addition request
Viannis SANE_CAP_COLOR is, in contrast to the below data structure, a
macro defined flag for the SANE_Option_Descriptor::cap.
The suggested flag is API and ABI backward compatible. So this change will
be a very light one.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
Date: Sat, 20 Jun 2009 14:42:07 +0200
From: Alessandro Zummo azummo-lists at towertech.it
We could grow SANE_Parameter with a flags field and a version field:
typedef struct
{
SANE_Int version;
SANE_Word flags;
SANE_Frame format;
SANE_Bool last_frame;
SANE_Int bytes_per_line;
SANE_Int pixels_per_line;
SANE_Int lines;
SANE_Int depth;
}
SANE_Parameters;
[sane-devel] API addition request
On Sat, Jun 20, 2009 at 3:21 PM, Kai-Uwe Behrmann ku.b at gmx.de wrote:
Viannis SANE_CAP_COLOR is, in contrast to the below data structure, a macro
defined flag for the SANE_Option_Descriptor::cap.
The suggested flag is API and ABI backward compatible. So this change will
be a very light one.
yes- I dont think anyone will object to this. however, no backends will set
the bit without a change, so then you are forced to assume it is always on,
even when it is off. If we make it part of a sane 2 standard, then we can
require that backends set the bit properly.
allan
kind regards
Kai-Uwe Behrmann
--
developing for colour management www.behrmann.name + www.oyranos.org
Date: Sat, 20 Jun 2009 14:42:07 +0200
From: Alessandro Zummo azummo-lists at towertech.it
We could grow SANE_Parameter with a flags field and a version field:
typedef struct
{
SANE_Int version;
SANE_Word flags;
SANE_Frame format;
SANE_Bool last_frame;
SANE_Int bytes_per_line;
SANE_Int pixels_per_line;
SANE_Int lines;
SANE_Int depth;
}
SANE_Parameters;
--
sane-devel mailing list: sane-devel at lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject unsubscribe your_password
to sane-devel-request at lists.alioth.debian.org
--
The truth is an offense, but not a sin
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/d8bcfa32/attachment.htm
