[sane-devel] CanoScan Lide 110 on Ubuntu 10.10
Am 10.03.2011 01:26, schrieb Warren Turkal: What backend does that scanner allegedly use? wt On Wed, Mar 9, 2011 at 7:45 PM, stef stef.dev at free.fr mailto:stef.dev at free.fr wrote: Le Wednesday 09 March 2011 16:17:17 Tammo Heeren, vous avez ?crit : If you mean with 'sudo ...'. Yes. On Wed, 2011-03-09 at 07:45 -0500, m. allan noah wrote: did you try as root? allan On Wed, Mar 9, 2011 at 1:52 AM, Tammo Heeren home at tammoheeren.com mailto:home at tammoheeren.com wrote: I am really hopping that somebody can help me. I am at a loss. I have a CanoScan Lide 110 on Ubuntu 10.10. sane-find-scanner returns found USB scanner (vendor=0x04a9 [Canon], product=0x1909 [CanoScan], chip=GL124) at libusb:002:005 (which it should) however, scanimage -L just returns the usual No scanners were identified. scanimage -V returns scanimage (sane-backends) 1.0.23git; backend version 1.0.23. I added myself to all kinds of groups, ran everything with sudo, to know avail. Neither xsane and simplescan work. Can anybody point me in the right direction. I'd really like to get this thing working and be one step further away from windows. Tammo Hello, there is no need using latest git version for LiDE 110. Support for this model is complete in SANE 1.0.22. If the release is available in the official package repository, you should use it. If not you might have a look at https://launchpad.net/~robert-ancell/+archive/sane-backends https://launchpad.net/%7Erobert-ancell/+archive/sane-backends I have seen similar problems with a simple LIDE20. I needed git in order to run that scanner on ubuntu 10.04. It was about try and error. Would'nt it be nice, if scanimage and sane-find-scanner use the same routines to detect a scanner? Then in case of a conflict, scanimage could do some further analysis and give more meaningful messages to users. Users are typical bad at guessing about program internals, me included ;-) kind regards, Kai-Uwe
[sane-devel] API addition request
Am 24.08.10, 10:06 +0200 schrieb Johannes Meixner: Hello, On Aug 20 11:50 m. allan noah wrote (shortened): Johannes- If we had two trees, and they used the same soname/soversion such that only one could be installed at a time, which one would SUSE ship? The old, no changes version, or the new, more features, might break some frontends version? I would provide both in two separated RPMs with different RPM names where both RPMs provide the same RPM capability sane-backends but with mutual RPM conflicts tags to make sure that only one can be installed at the same time. Furthermore I would enhance our YaST scanner module to support switching back and forth between them so that our users can try out which they like more. It would depend on user feedback (in particular during our beta-tests for an upcomming openSUSE version) if we prefer the old one to be installed by default or the new one. We did the same kind of switching for our printing system: From LPRng+lpdfilter to CUPS. As long as a setup tool (like YaST) provides the end-user an easy way to switch back and forth there is no real problem. Initially the old stuff was the default, then we switched to the new stuff as default (this is the actual switch from the end-users point of view), and a longer time later we dropped the old stuff - first we dropped support for the old stuff in YaST but kept its RPM packages and at the very end we dropped also the old stuff packages. Via our openSUSE build service I can provide a new sane-backends at any time via a separated package repository so that interested users can install it on demand whenever they like (but there would be no automated replacement of an installed sane-backends package on a user's system). Can you please post your OBS repository with the patched sane-backend. I would like to use it to build the Oyranos SANE configuration module. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
Am 19.08.10, 20:39 -0400 schrieb m. allan noah: While I am of the opinion that he deserves to feel some pain for that kind of horrible code, the end user of his code does not deserve breakage. I really, really want to commit your patch (after changing to the US spelling :) but I cannot, as the possibility of breakage is enough. I understand now the reasoning. Nonetheless I might provide a patched version for specialised graphics distributions, with US spelling ;-) kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
Am 20.06.09, 16:37 -0400 schrieb m. allan noah: 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 Ping :) Any chance to get the supplied patches accepted in the current sane-backends git? https://alioth.debian.org/tracker/index.php?func=detailaid=312641group_id=30186atid=410366 kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
Am 19.08.10, 12:23 +0200 schrieb Julien BLACHE: Kai-Uwe Behrmann ku.b at gmx.de wrote: Any chance to get the supplied patches accepted in the current sane-backends git? In the current state of things, no. Does this relate to the patches themself or is it outside of my scope? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
Hello, Am 19.08.10, 17:35 +0200 schrieb Julien BLACHE: Kai-Uwe Behrmann ku.b at gmx.de wrote: Does this relate to the patches themself or is it outside of my scope? It relates first and foremost to the state of SANE, SANE2, etc, etc. The patches are for SANE only and have API and ABI wise not much side effects. Most apps will work as usual. Some apps can make use of the additional informations from the patch. But there is no requirement to do so. Is SANE already frozen? If the SANE_CAP_COLOR flag will be a design decission for SANE2 as well thats fine, but no precondition for its usefulness in SANE. With the experiences in SANE there will come experience and ideas about how to best add a similiar or better feature to SANE2. Unfortunately we seem to be stuck right now with no solution in sight and as it is we wouldn't have enough manpower to produce a revamped version of SANE :/ I know of that difficult situation. However, having the patch applied to git would save us work in later patching sane by hand and convincing distributors to do as well. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
Hello, Am 19.08.10, 18:22 +0200 schrieb Julien BLACHE: Kai-Uwe Behrmann ku.b at gmx.de wrote: SANE 1 has always been frozen, and an attempt at thawing it a bit to extend the API/ABI in a backward-compatible way has failed spectacularly. Now, I see my subject line was misleading. The SANE_CAP_COLOUR is merely a flag. So I would suggest a API/ABI checker can not detect that. All the patch needs in the headers is: +++ include/sane/sane.h #define SANE_CAP_ADVANCED (1 6) +#define SANE_CAP_COLOUR(1 7) The remainder is in the backends. So unless we want to restart that effort, I don't see how your patch can get merged in SANE 1. I shurely would not want that. Not that I don't want it, note. Thanks for considering. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] colour options patches 1
The SANE backend patches are now attched here: https://alioth.debian.org/tracker/index.php?func=detailaid=312641group_id=30186atid=410366 kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org Am 30.07.10, 11:01 +0200 schrieb Kai-Uwe Behrmann: The SANE_CAP_COLOUR flag was suggested as a new flag to mark colour related options. The attached patches contain the according changes to the actual sane-backends in git master. sane_cap_colour.patch is a patch to introduce the SANE_CAP_COLOUR flag and flags the the pnm backend options. sane_cap_colour_plustek.patch flags the plustek options. Both patches where prepared by Yiannis Belias. A thierd patch containing the ramaining backend changes will follow.
[sane-devel] colour options patches 1
The SANE_CAP_COLOUR flag was suggested as a new flag to mark colour related options. The attached patches contain the according changes to the actual sane-backends in git master. sane_cap_colour.patch is a patch to introduce the SANE_CAP_COLOUR flag and flags the the pnm backend options. sane_cap_colour_plustek.patch flags the plustek options. Both patches where prepared by Yiannis Belias. A thierd patch containing the ramaining backend changes will follow. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org -- next part -- A non-text attachment was scrubbed... Name: sane_cap_colour.patch Type: text/x-patch Size: 3383 bytes Desc: URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100730/e32cab17/attachment-0002.bin -- next part -- A non-text attachment was scrubbed... Name: sane_cap_colour_plustek.patch Type: text/x-patch Size: 8092 bytes Desc: URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100730/e32cab17/attachment-0003.bin
[sane-devel] colour options 2
Here comes the second gzipd patch from me for the remaining backends. We would be glad you review and hopefully commit these patches for more robust ICC profile to device driver settings association. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org -- next part -- A non-text attachment was scrubbed... Name: sane_cap_colour_backends.patch.gz Type: application/x-gzip Size: 23237 bytes Desc: URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100730/e1ffa442/attachment-0001.bin
[sane-devel] Rendering Intent for Color Management in XSANE Setup
Am 28.07.10, 23:08 +0200 schrieb Stephan Maier: On 07/28/10 13:28, Kai-Uwe Behrmann wrote: Date: Wed, 30 Jun 2010 13:59:33 -0400 From: Stephan Maier stephan at bwh.harvard.edu I found a clear discrepancy between the profiling results achieved with XSANE and the Argyll (www.*argyllcms*.com) converting routine cctiff. The Argyll profiling results agree perfectly with the expected values for my target image. I was able to reproduce the XSANE results with Argyll's cctiff by using the same rendering intent, i.e. perceptual, for both input profile (XSANE: Scanner default color ICM-profile) and output profile (XSANE: Working color space ICM-profile). ICC profiles typical connect to the Profile Connection Space (PCS). This is eigther Lab or XYZ encoded. During a colour trasnformation your input profile connects to PCS and then goes to output profile, the working or editing space. For a colour trasnformation is only one rendering intent possible. I agree with the first part. Thus we have raw data (scanner) -- PCS -- output Now, as I understand it, each arrow represents a color transformation with its own rendering intent. In XSane does the rendering intent apply to both transformations or only the second one? One could of-course set the first to 'absolute colorimetric' by default and the user defined rendering intent would then only apply to the second one. While using distinct profile colour transforms for the above conversion is technical possible, the intention is to use the tables in pairs. This leads me to believe the Rendering Intent choice in XSANE setup applies to both in input and output profile. This approach is not correct, however. The rendering intent of the input profile, which corrects errors of the scanner, has to be set to Absolute colorimetric, since all other choices perform a white point correction. XSANE lacks the option Absolute colorimetric results in a native input whitepoint on the output media. E.g. the colour cast of the device would be projected into D50 or whatever the editing space is and would appear there in. This is useful mostly in pedantic reproduction. Normaly relative colorimetric with black point compensation performs more desirable. Yes, I agree that 'absolute colorimetric' is the least useful for output and that it keeps the whitepoint coordinate and that perceived whites appear no longer white. However, for the input calibration profile it is different since we indeed need a pedantic transform, since the raw data is not in a color space yet. The device colour space should be described by the device ICC profile. Assigning the profile to the image or embedding is enough for defining the colours of the raw data. to set this rendering intent independently of the rendering intent for the output profile (typically the desired output profile intent is perceptual or relative colorimetric). If there is no thierd profile involved in the colour workflow, there can by definition be no second rendering intent. This is may be my misunderstanding, but as I outlined above, the raw data to PCS transform I consider to be separate profile, which should have it's own rendering intent or at least a suitable default value, like absolute colorimetric. It makes no sense to me. Absolute colorimetric is delivered by the AToB1Tag and the mediaWhitePointTag. The system is not designed to be used with different rendering intents per transform. From and to PCS does not count. inProfile - PCS - outProfile is considered one transform. The PCS is not defined to have an additional step. The PCS is designed to build the transform in a predictable, CIE*XYZ/CIE*Lab is well known, and a exchangable way. PCS allowes to combine different profiles without knowing in advance of them. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] Re: Rendering Intent for Color Management in XSANE Setup
Date: Wed, 30 Jun 2010 13:59:33 -0400 From: Stephan Maier stephan at bwh.harvard.edu I have been verifying the Color Management in XSANE. Great. Do you have a link to a web page with your results? I found a clear discrepancy between the profiling results achieved with XSANE and the Argyll (www.*argyllcms*.com) converting routine cctiff. The Argyll profiling results agree perfectly with the expected values for my target image. I was able to reproduce the XSANE results with Argyll's cctiff by using the same rendering intent, i.e. perceptual, for both input profile (XSANE: Scanner default color ICM-profile) and output profile (XSANE: Working color space ICM-profile). ICC profiles typical connect to the Profile Connection Space (PCS). This is eigther Lab or XYZ encoded. During a colour trasnformation your input profile connects to PCS and then goes to output profile, the working or editing space. For a colour trasnformation is only one rendering intent possible. This leads me to believe the Rendering Intent choice in XSANE setup applies to both in input and output profile. This approach is not correct, however. The rendering intent of the input profile, which corrects errors of the scanner, has to be set to Absolute colorimetric, since all other choices perform a white point correction. XSANE lacks the option Absolute colorimetric results in a native input whitepoint on the output media. E.g. the colour cast of the device would be projected into D50 or whatever the editing space is and would appear there in. This is useful mostly in pedantic reproduction. Normaly relative colorimetric with black point compensation performs more desirable. to set this rendering intent independently of the rendering intent for the output profile (typically the desired output profile intent is perceptual or relative colorimetric). If there is no thierd profile involved in the colour workflow, there can by definition be no second rendering intent. Stephan Maier kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] Re: ICC, white marks, gamma table, scaling artifacts
Date: Wed, 14 Jul 2010 17:03:56 -0700 From: Grant emailgrant at gmail.com ICC I've posted on this subject before and Allan told me I should scan a color target along with my scans so I can apply an ICC profile. Can I order a color target online? Is there a particularly one to get? There are many colour target providers online. The L-Prof site mentions one: http://lprof.sourceforge.net/links.html kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
Am 20.06.09, 16:37 -0400 schrieb m. allan noah: 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 thanks the bit without a change, so then you are forced to assume it is always on, Agreed, a patch covering the sane included backends should be created and proposed by us. 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. Agreed for sane 2 to official support the SANE_CAP_COLOR flag. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
Am 21.06.09, 12:33 +0200 schrieb Alessandro Zummo: On Sun, 21 Jun 2009 09:50:33 +0200 (CEST) Kai-Uwe Behrmann ku.b at gmx.de wrote: 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. Agreed for sane 2 to official support the SANE_CAP_COLOR flag. Should the default behaviour of a backend not to alter the color output as much as possible? This is a difficult question for the transistion period. Currently Xsane and scanimage can apply colour profiles on the frontend side. They do not know if a image is prematched or in some more native device space? I could imagine one backend option like: colour-convert - system, not in backend [0] (default) - backend to sRGB, not in system [1] The first value would allow the frontend to take over profile selection, while the later works as last rescue for colour management unaware frontends. This option should remain non mandatory and almost not used or implemented. Colour management in backends is regarding user interaction a complex thing. It will confuse users easily and increase support requirements. If something does not work, it can not even called a bug, it will be called quickly bad design. If the system cares for this stuff or there is a relyable path to communicate a ICC device profile, its all easier - even though still not simple. Of course we need to define a path for vendors to deliver their device profile along with a driver and correctly install them. This is work to do. I recently noticed, while working on the epson2 color correction profiles, that the default option told the scanner to adapt for CRT monitors. ... for preview pourpose? I'm planning to introduce profiles shortly and to revert this default to no correction. Yes, fine. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[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] ICC support - summing up
Date: Tue, 09 Jun 2009 11:53:51 +0200 From: Julien BLACHE jb at jblache.org I thought the Oyranos repository was central, but it's actually on the machine. I'm really not sure about that in an environment with a lot Yes, Oyranos works primarily local. Its not a networked colour server. Networking is typical done inside the device protocols of X11 and hopefully CUPS. It would make no sense to reinvent all that security relevant network stuff. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] ICC support for SANE
Date: Fri, 29 May 2009 09:56:16 +0200 From: Julien BLACHE j...@jblache.org Yes, but I'm not sure how well this is supported by frontends. XSane supports it but then saving in at least some formats goes down to 8bit. PNG and Tiff can handle 16-bit per channel. The = 8-bit version of Jpeg is not so commonly used. Date: Fri, 29 May 2009 17:32:51 +0900 From: Olaf Meeuwissen olaf.meeuwis...@avasys.jp Seriously, my point is that some SANE backends do fiddle with the colour before returning the image data to the frontend. TTBOMK the SANE spec has nothing to say on whether that is allowed or not, so the safest thing to assume is that it will happen. Whether that has any knock-on effects for ICC, I leave to the experts to decide. Multiple ICC colour conversions are mostly bad. The typical conversions are interpolations. In few special cases round tripping is ok. But this will almost not apply to scanner profiles (or printer and most camera ones). Attributes to option names: What would help to get things at higher API levels is tagging of options according to their colour relevance. This allowes frontends to automatically select a configured profile. One way could be to define certain appendings to existing option names are to be considered as attributes and not as as part of the option name itself. Lets say all chars after a '.' point are considered to be attributes for SANE_Option_Descriptor::name : e.g. sane_option_gamma_r = sane_option_gamma_r.colour This could then tell about the colour relevance of the hypothetical sane_options_gamma_r. This could be suggested to allow more advanced stuff at higher API levels. ICC in backends: For colour matching in backends is not so easy to get through all necessary informations. It is as well unfortune for a system, as having to control in man places can easily fail. To specify a path for transportation of ICC profiles from each backend would increase the effort for all backend maintainers. So I guess it is not a good route. (This does not touch the desire to transport ICC profiles over the network outside of backend API's, even if that sounds not Sane architecture friendly.) kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] ICC support for SANE
Am 28.05.09, 12:13 +0200 schrieb Julien BLACHE: Kai-Uwe Behrmann ku.b at gmx.de wrote: Hi, I'm pretty sure the frontend knows all there is to know about the scanner and its settings to retrieve the corresponding ICC profile. We possibly where holding our breath for something appearing like arbitrary per backend settings ;-) It helps to know that backend settings are well known and their relevance to colour can be understood on the application level. There is no standard for scanner settings. Each model has different settings available, with the most common settings somewhat standardised and dubbed well-known options in SANE. That's all you've got to work with. Ah, so arbitrary settings are possible. This will make some instance necessary to decide, which setting is colour related and which not in order to automatically honour only related settings for ICC profile selection. E.g. a profile for each scan area makes less sense. As well the selection of colour settings for inclusion into a profile by users is error proune. All settings should be available to the frontend. If there is something set/computed behind the scene by the backend that is not reflected in the options or scan parameters available to the frontend, I'd tend to consider that a bug. Such a parameter should probably be exposed to the frontend in the form of a read-only (non settable) option. Good. Just as in your DigiKam example, where gphoto2 is not involved whatsoever with the ICC stuff. Well, gphoto2 appears as a local transportation layer without any colour influence. We just learned that. Sane influences the colour and transports remotely. So, there are more variables to consider. I don't think we have backends messing around with colours directly, Lots of settings hold gamma, saturation and so on in their names. So I assume eigther the device or the driver does manipulations. except: - the v4l backend which does image conversion through libv4l, and conversion means losses in any case. Nobody cares about v4l, though. - backends for machines that send the image as a JPEG. I think we have one or two cases of that, and the JPEG is decompressed to RGB. Someone will correct me if I'm wrong here. And more importantly, but I'm not sure we have a case of that: - machines that send data with samples 8 bits So in the end we should be pretty much transparent, sending out parameters and getting back image data. There's little to no image processing done in the backends, except line distance correction. Ideally the profile selection should be dependent on any colour processing, be the processing in hardware or software. Burdening the guesswork of selecting the right profile to users is too complicated und non relyable. I don't know all the backends and what they do, so hopefully backend maintainers will comment about their backend if needed :) Yiannis, suggests to handle transportation of ICC profiles over the network at a later stage. This approach will be less sprinkling than to work on each backend individualy. I don't think it brings anything. If you are scanning via the network and you care about ICC profiles, I'd say your Oyranos repository/server is available on the same network anyway. AKA you're not scanning on an unknown machine at an unknown location anyway. A user obtains not necessarily a login on a machine, where (s)he scanns or prints. A second transport path is overhead to administrators. Duplicating and maintaining lots of resources on each machine is not fortune. But if you want to do that, it'll have to be out-of-band anyway. Using Why not inside the normal Sane network traffic? All what is needed is to forward a request to the remote location to obtain some data. a read-only option is going to be a gigantic waste of bandwidth. Look Well I dont know why something has to be a read-only option. A one time request would be all which is needed. Ok when colour options change then more. at how many times the options get reloaded, and you'll understand why. I've recently talked ICC profiles with people in the imaging/printing business, and I've got told (not an accurate quote) nobody cares about ICC profiles; it doesn't work out, it's near impossible to get right, it's a waste of time, it doesn't really make a difference in the end anyway. Beside many problems waiting to be solved, for people who want or have to care about colour there are not many alternatives to ICC profiles. Setting up one local machine for work with end to end colour management is certaily possible on linux. With some work it might even scale to some extent. Obviously the remains some work to make the scaling of ICC style colour management easy on linux/bsd. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] ICC support for SANE
replying to digest Date: Mon, 11 May 2009 09:40:43 -0400 From: m. allan noah kitno...@gmail.com On your blog posts, I think your list of how to get device identification is good except for a few points- 3. there is a version number exposed by the backend, but only as a param of sane_init() 4. You should not make assumptions about which driver options might change the output of the machine. Brightness/contrast/gamma are common, but others might include exposure, or black level, or even some sort of dynamic algo done by the scanner itself. 5. you might also want to adjust your work-flow drawing to show the SANE backend between the scanner and the SANE API. How can we see what the backend does? I mean it is quite essential regarding colour apeparance to know, with which settings a scanner runs, e.g. gamma, gain ... Is this exposed in the Sane API? As initial interesst for Sane related colour management is very old, I got some first steps from here, some the following notions might be already know. Anyway, let me elaborate: when one calibrates and profiles a scanner, hopefully good settings are used and the colour related part should be extracted and remembered somewhere. Ideally these setting are stored later in the final ICC device profile. A hardware driver knows possibly best which settings are colour related and which not. Therefore I plan to add a backend type to Oyranos, which links to a device driver, e.g. the Sane API, and serialises the colour related device settings ideally to a list of key/value text pairs. The Oyranos device backend of Yiannis will then recieve a Sane context from the frontend application and extract all colour related informations. The resulting information from the Sane scanner can then be stored in the Oyranos device profile DB and embedded into a ICC profile on request. [1] What this approach would be in need of, is some means to obtain colour relevance from a backend. Can all colour relevant settings be marked and transported to the front end? Would this be an extension or already available in Sane? The calibration part is done by a application, like for monitors and often or printers. This can be automatic or manual. After this phase the device is ready for measuring. The settings, used during the calibration, must be stored or at least not altered. It is always a good idea to have control over that settings, as a change of them will change any later output and invalidate the ICC profile. The calibration can be imagined like a reference for the ICC profile. [2] The test scan, typical of a colour patches chart, will then show the result of that colours scanned under these calibration. The obtained picture can then be feed to a profiling application, like ArgyllCMS or Lprof in the open source world. It will extract the resulting colours as device colours and create a ICC profile, which is able to correct these colours to a reference colour space. Applications using following combination of: * a defined or, regarding colour, similiar behaving device * a defined driver (backend?) settings and * a related ICC profile can then reach much more agreement about colours for the same scanned picture with different devices. Ideally the tint of the device will disappear after that process. The application part is already implemented in XSane. [3] Now related to Oyranos, the idea is to move that device, driver, ICC profile combination out of a single application to a shared library, to offer every application using colour devices the same comfort of obtaining ICC colour management support from the Oyranos library. This includes a GUI to set profiles to each device and other options. The GUI part is called kolor-manager, a KDE system settings panel, which is currently part of the KDE playground [4]. There has been some discussion of making a modified version of the SANE API, perhaps if you can outline the benefits of ICC support, you might get some buy-in to adjust it to your needs... Date: Mon, 11 May 2009 16:22:53 +0200 From: Julien BLACHE j...@jblache.org To put it in a nutshell: uniquely identifying a scanner, don't count on it. If it was doable, we would have done so loong ago already. What a pitty. Fact is, USB scanners reporting a serial number at the USB level are the exception. And as Allan wrote already, even otherwise, not a lot of machines expose a serial number. Manufacturers just don't care, except on high-end machines. Then these machines will probably see less troubles during colour critical work. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://www.oyranos.org/wiki/index.php?title=Device_Settings#Driver [2] http://www.oyranos.org/wiki/index.php?title=Device_Settings#Profiling [3] http://www.oyranos.org/wiki/index.php?title=Device_Settings#Scenario [4] http://www.oyranos.org/wiki/index.php?title=Kolor-manager
[sane-devel] Git repositories are up
Date: Mon, 04 May 2009 19:02:07 +0200 From: Julien BLACHE j...@jblache.org HTTP access for cloning for the corporate-firewall-impaired among us: git clone http://git.debian.org/git/sane/sane-backends.git git clone http://git.debian.org/git/sane/sane-frontends.git git clone http://git.debian.org/git/sane/website.git alternatively one may access git over the git port (9418/tcp): git clone git://git.debian.org/git/sane/sane-backends.git git clone git://git.debian.org/git/sane/sane-frontends.git git clone git://git.debian.org/git/sane/website.git see as well: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-git ... The git protocol gives better performance and reliability ... kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] xsane-0.992 released
Hello Oliver, for grayscale images exist special gray scale profiles. You have no device profile selector for them to explicitely support that kind of conversion. Yes, omit preceptual and saturation. In PS they are not to be found anyway under theyre rendering intent names (and works slightly different than in lcms). The only use of distinguishing them is to show the media whitepoint (or paper colour) on screen or to adapt to the monitor whitepoint. kind regards Kai-Uwe Behrmann -- development for color management www.behrmann.name + www.oyranos.org + www.cinepaint.org Am 27.01.07, 22:57 +0100 schrieb Oliver Rauch: Hello Kai-Uwe, thanks for your test/comments. I also had problems with grayscale scans, but I did not find out what the problem is. May be the profiles I use do not support grayscale. But I am also not sure how grayscale conversion is done with color management. I read that usual proofing intents are relative and absulute colorimetric. Should I disable the others because it does not make sense at all to use them or are there any situations in which they make sense? Best regards Oliver Am Freitag, 26. Januar 2007 16:37 schrieb Kai-Uwe Behrmann: Except gray scales it works. The proofing intents cover usually relative and absolute colorimetric only. The test scan was saved with the embedded scanner profile. Opened in CinePaint the image looked the same as in Xsane's preview. Switching colour management on and off showed the difference. kind regards Kai-Uwe Behrmann -- development for color management www.behrmann.name + www.oyranos.org + www.cinepaint.org Am 25.01.07, 22:52 +0100 schrieb Oliver Rauch: Hello. XSane-0.992 is released. It contains some bugfixes and rudimentary color management support. Please consider this version as beta-code, it may crash or create unespected results. You find it on http://www.xsane.org Best regards Oliver
[sane-devel] xsane-0.992 released
How can I test without an scanner connected? xsane sane-pnm and xsane sane-pnm:xsane-calibration.pnm and sane-test equivilants seems not to work eighter? Installed is sane 1.0.14 distributed on Feb 2005. kind regards Kai-Uwe Behrmann -- development for color management www.behrmann.name + www.oyranos.org + www.cinepaint.org Am 25.01.07, 22:52 +0100 schrieb Oliver Rauch: Hello. XSane-0.992 is released. It contains some bugfixes and rudimentary color management support. Please consider this version as beta-code, it may crash or create unespected results. You find it on http://www.xsane.org Best regards Oliver
[sane-devel] xsane-0.992 released
?tienne, thanks for the hint. Xsane opens and at least I can select across 4 generated test images. kind regards Kai-Uwe Behrmann -- development for color management www.behrmann.name + www.oyranos.org + www.cinepaint.org Am 26.01.07, 13:36 +0100 schrieb ?tienne Bersac: Hi, xsane sane-pnm and xsane sane-pnm:xsane-calibration.pnm and sane-test equivilants seems not to work eighter? use xsane pnm or xsane test or configure /etc/sane.d to load test backend (uncomment test in dll.conf) ?Tienne. -- Verso l'Alto ! From k...@gmx.de Fri Jan 26 16:37:06 2007 From: k...@gmx.de (Kai-Uwe Behrmann) Date: Fri Jan 26 16:37:49 2007 Subject: [sane-devel] xsane-0.992 released In-Reply-To: 200701252252.45943.oliver.ra...@rauch-domain.de References: 200701252252.45943.oliver.ra...@rauch-domain.de Message-ID: Pine.LNX.4.61.0701261623580.6730@sirius.rasena Except gray scales it works. The proofing intents cover usually relative and absolute colorimetric only. The test scan was saved with the embedded scanner profile. Opened in CinePaint the image looked the same as in Xsane's preview. Switching colour management on and off showed the difference. kind regards Kai-Uwe Behrmann -- development for color management www.behrmann.name + www.oyranos.org + www.cinepaint.org Am 25.01.07, 22:52 +0100 schrieb Oliver Rauch: Hello. XSane-0.992 is released. It contains some bugfixes and rudimentary color management support. Please consider this version as beta-code, it may crash or create unespected results. You find it on http://www.xsane.org Best regards Oliver
[sane-devel] EPSON 3490, calibration and raw data
Krzysztof,
not an insider of sane programming, but some comments below:
Am 11.02.06, 13:54 +0100 schrieb Krzysztof Halasa:
Hi,
Please forgive my ignorance, I've just started using EPSON 3490.
I'm especially interested in scanning negative 35 mm films (yes, I know
it's low-end, it's like an experiment).
Reading the sources to snapscan backend I got the impression that:
a) before the actual scanning the scanner performs white level calibration
(and, with TPU, black level calibration).
This is actually READ/READ_CALIBRATION and READ/READ_CALIBRATION_BLACK
and the scanner just scans 16 lines of open area behind the actual
film (and respectively 48 lines for black calibration, not sure where).
The images are either 8-bit or 16-bit, but I'm not sure all bits are
used (details?).
b) the scanned calibration image is averaged and a single line is sent
back using SEND/READ_CALIBRATION and SEND/READ_CALIBRATION_BLACK.
Not sure about 16-bit, does the values differ from 8-bit mode?
c) eventually the analog gamma information is uploaded to the scanner
as well (not yet sure about details, someone?).
What do I need? I need to obtain raw scan data, without any calibration
or gamma correction at scanning time.
My expectation about indevice gamma correction, it is a mathematical
conversion to the full bit depth. Thus the native 10/12/14-bit signal is
fixed in the AD unit and anything like gamma and B/W point is applied to
this stream. If someone with more technical insight can negate it would
be interessting on how to manipulate the AD conversion.
Now I have disabled READ/READ_CALIBRATION* command and the whole averaging
etc. and I'm doing SEND/READ_CALIBRATION* with the following data:
- for white: 255 0 0 0 ...
- for black: 0 0 0 0 ...
Does it disable the calibration and related calculations? The following
code fragments suggests so but the algorithm seems a bit strange (for black
and white but it essentially the same for RGB):
/* now make averages */
for (k = 0; k num_bins; k++) {
bins[k] /= cal_lines;
/* also divide by 64 for 16bit mode */
if (bytes_per_bin == 2)
bins[k] /= 64;
}
and then:
g = 0;
for (k = 0; k num_bins; k++) {
*pbuf++ = bins[k] - g;
g = bins[k];
}
Why the /64? Does the calibration data in 16-bit mode consist of 8-bit
samples shifted left by 6 bits (i.e., 14-bit samples with lower 6 bits
unused/ignored)?
Next thing, analog gamma - does setting it to 1.0 prevents scanner
firmware from doing any calculations?
Is this scanner really 48-bit (3 * 16 bit)? Can I really get full 16-bit
data from it?
This certainly not for the above device. I would guess 10-14 bit with
appropriate noice. Multisampling helps for the latter. You have to test if
the tonal range is good enough for negative scanning. Not shure if newer
consumer scanners are better in this field.
Do you think adding get raw data option and possibly get calibration
data (for further processing with general image-manipulation programs)
to this backend would make sense?
Any help will be appreciated.
--
Krzysztof Halasa
regards
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: k...@gmx.de
+ http://www.behrmann.name
[sane-devel] unique device infos
The goal is identification of devices to assign colour profiles precisely. I like to take an normal userspace application and do an query to an library (sane) which will provide the mentioned information about the image output. The manufacturer/model/ID information will then be used to select the correct profile for that device. What does You think are such informations reachable? regards Kai-Uwe Behrmann + development for color management + imaging / panoramas + email: k...@gmx.de + http://www.behrmann.name Am 17.02.05, 09:30 +0100 schrieb Gerhard Jaeger: On Monday 14 February 2005 09:36, Kai-Uwe Behrmann wrote: Hi, does sane currently export device informations like: manufacturer, model and ID/serial number? This would help me in further processing the output of sane. thanks Kai-Uwe Behrmann Could you be more specific! What would you like to do? Any proposal? Gerhard
[sane-devel] unique device infos
Hi, does sane currently export device informations like: manufacturer, model and ID/serial number? This would help me in further processing the output of sane. thanks Kai-Uwe Behrmann + development for color management + imaging / panoramas + email: k...@gmx.de + http://www.behrmann.name
[sane-devel] Saphir Ultra II color changes?
Till friday I had much to do. So my answere comes today as I continued to test. Am 03.04.03, 18:27 +0200 schrieb Oliver Rauch: May be you have a problem with the lamp or the calibration. What results when you do: - preview #1 - scan #1 - preview #2 - scan #2 (always the same areas and images). The differences between preview and scan are constant over time. As the result of some testing I could see, equal to positiv and all negative scanning combinations, the changes of colors came while using other settings than full range from the filmtype selector. The more the film type preadjusts the image the more will be color changes between preview and final scan visible. For Negatives it is better visible than with postives. Oliver -- Kai-Uwe
[sane-devel] Saphir Ultra II color changes?
-- I hope this is not a duplicated mail for You, my SuSE8.0email is :( -- Hi Oliver, sorry I maybe said it somewhat unclear. The rgb-pixels align right - no geometric shift. The difference from preview to final scan is: I see an yellowish preview an get an bluish scan. It locks like xsane uses an other method for preview than for the final scan. I remember to have read about gammatables in the scanner versus gamma correcting in (x)sane, this would give an good explanation. Kai-Uwe - Good informations depends on our courage to bear them. - - Desinformation may become very inconvenient sometimes. - - http://www.indymedia.org - Am 02.04.03, 21:31 +0200 schrieb Oliver Rauch: Hello. The SAPHIR4/PL-III put the colors together to one line in the scanner, not in the driver. I myself use the PL-III without such problems. Please send a SMALL example image to me (not to the list). Best regards Oliver On Wednesday 02 April 2003 19:48, Kai-Uwe Behrmann wrote: Hi Listmenbers, I compiled sane-1.0.11 from source to solve some problems with the Linotype SAPHIR4 alias Saphir Ultra II equal to PL-III. As reported earlier the preview of xsane(0.90) and the final scan are very different. This happens to the SU-II as well. Following a hint to solve this, I tried to update sane as it was expected to be driver related. Now sane compiles and shows me the scanner but dont like to support him instantly. sane-find-scanner: found SCSI scanner Linotype SAPHIR4 V1.5 at device /dev/sg1 scanimage -L showed only after some compilations of sane the scanner The previously used sane-1.0.7 and -1.0.8 from SuSE worked without any problems. (Would like to know what they did.) I checked the umax*.* files and it looked to me as all would be proper - Linotype SAPHIR4 was defined as supported on some lines. Now as I can use sane-1.0.11 the situation is the same: big color shifts between preview and final scans. Is it possible to aviod the different scanmodes of preview and final scanns via an option till it is debuged? Nevertheless, Thanks for the work. Kai-Uwe ___ Sane-devel mailing list sane-de...@www.mostang.com http://www.mostang.com/mailman/listinfo/sane-devel -- http://www.xsane.org http://www.mostang.com/sane http://www.rauch-domain.de mailto:oliver.ra...@rauch-domain.de
[sane-devel] Saphir Ultra II color shifts?
Hi Listmenbers, I compiled sane-1.0.11 from source to solve some problems with the Linotype SAPHIR4 alias Saphir Ultra II equal to PL-III. As reported earlier the preview of xsane(0.90) and the final scan are very different. This happens to the SU-II as well. Following a hint to solve this, I tried to update sane as it was expected to be driver related. Now sane compiles and shows me the scanner but dont like to support him instantly. sane-find-scanner: found SCSI scanner Linotype SAPHIR4 V1.5 at device /dev/sg1 scanimage -L showed only after some compilations of sane the scanner The previously used sane-1.0.7 and -1.0.8 from SuSE worked without any problems. (Would like to know what they did.) I checked the umax*.* files and it looked to me as all would be proper - Linotype SAPHIR4 was defined as supported on some lines. Now as I can use sane-1.0.11 the situation is the same: big color shifts between preview and final scans. Is it possible to aviod the different scanmodes of preview and final scanns via an option till it is debuged? Nevertheless, Thanks for the work. Kai-Uwe
