> Not necessarily: It is possible to have ICC profiles that only contain > a matrix ("matrix shaper profile").
OK, in this case the LUTs are simply neutral (1:1) or can at least be handled as such. > > 2. Exposure can be incorporated into the first LUT. This would avoid a > > LUT that discards the top (bright) end of the scale, therefore not > > making ideal use of the CCD's noise performance. > > That is if the scanner actually supports an exposure control. The scanners I > deal with (EPSON) don't expose this control. Yes, but most film scanners do. It makes things a bit more complicated in the sense that there is no such thing as absolute exposure for these scanners, and the ICC profiles assume one particular exposure setting. We can only speculate what these exposure settings are for the manufacturer-supplied ICC profiles. (I suggest they are probably the "full-white" ones that give maximum value for R, G, and B channels with a fully transparent object, i.e. no film.) So, my suggestion is that we define new well-known options for exposure in the R, G, and B channels (and maybe IR? -- Coolscan scanners don't allow IR exposure to be modified). This would be a fixed-point value acts proportionally, and the "full-white" setting corresponds to a value of 1. for each of the R, G, B channels. Obviously the backends would then have to have hardwired absolute exposure values that calibrate the scanner, or we could put these in the config file so that they can be adjusted (I'd prefer the latter). > The advantage of the first one is that Marti is an expert as far as color, > color management and ICC profiles go. LCMS is part of all major Linux > distributions and is used by e.g. ImageMagick. This means that there is > quite a bit of testing done on the lcms code, which probably is not > true for gcms. My vote is for lcms, even though we have you on the list. > With your gcms background, you should be able to pick up the lcms > functionality without any problems (that is, if you want to get into > this CM stuff in Sane at all). I agree. I'm happy to do the CMS stuff within xsane using lcms, but probably not in the next two months because I'm very busy. Here are two more issues that have just come to mind: - Some scanners support IR data and thus allow defect removal. This should really be done before the matrix is applied -- i.e., on the raw data retrieved from the scanner. I think there should be a meta-backend that does this, which can be fully transparent for anything else. (This would also separate the task of writing defect-removal code from everything else.) - It might be worth using standard orange-mask RGB values to simply manipulate a standard profile of the scanner rather than having to supply a profile for each scanner-film combination. I'm not sure this makes sense though. Good night, Andras =========================================================================== Major Andras e-mail: and...@users.sourceforge.net www: http://andras.webhop.org/ ===========================================================================