[Digikam-users] Printers with full Color Management

Milan Knížek knizek.confy at volny.cz
Sun Oct 4 08:31:07 BST 2009


Gerhard Kulzer píše v Ne 27. 09. 2009 v 08:55 +0200:
> On Friday 04 September 2009 09:47:24 pm Milan Knížek wrote:
> > 
> > AFAIK, the thing is that not all converters apply the same steps in the
> > same order and that some of the steps are variables affecting the raw
> > and rgb data. Some of the settings can be set by the user, some may be
> > hidden (and proprietary).
> > 
> > E.g. UFRaw applies white balance, highlight-reconstruction, wavelet
> > de-noising, raw curve adjustment, gamma and linearity before 
> assignment
> > of the camera profile.
> > 
> > Next problem is that the camera sensor does not react fully linearly to
> > the light - hence an icc profile prepared for a particular
> > white-balance/raw curve/etc. and used for another
> > white-balance/curve/etc may provide different result even in the same
> > raw converter.
> > 
> > If my understanding is wrong, I would be more then happy to know other
> > opinions.
> > 
> > P.S.2 The difference is quite obvious when using Canon's Digital Photo
> > Professional and UFRaw. There are methods how to find out, which ICC
> > profiles are used by DPP in MS Windows. However, people were usually 
> not
> > able to get the same output from UFRaw with those profiles. (I tried
> > myself and skipped this approach - the Adobe Matrices in dcraw based
> > converters provide better results).
> At least theoretically you are wrong in the sense that color management 
> should be independent of MS or Linux or whatever, it's the very sense of it. 
> CM transforms an image from one color space into another by transiting 
> through an ideal color space, it's a mathematical operation not dependent 
> on any drivers.
> But then there is the question as to whether the CM has been correctly 
> implemented by a specific program or driver.  

That is misunderstanding of the previous discussion - while we can
assume the differences between CM engines are reasonably small, the
first problem of impossibility to use DPP's ICC profiles for UFRaw lays
with the fact that different image data are fed to the CM engine. I.e. I
also agree with your statement (on the theoretical level).

In another words, if UFRaw was able to "develop" the same image data as
DPP does (i.e. demosaic, denoise, curve, white-balance, whatever
else...), then we could use DPP's ICC profiles in UFRaw, too.

> I've been trying to find out what profile Canon is using in DPP for my 30D, 
> then 40D and 50D. For the 30D I could track that DPP loaded a certain 
> profile, but for the 40D and 50D DPP doesn't seem to load any profile, it's 
> built-in. I've tried all profiles delivered with DPP on Linux with UFRaw and 
> digiKam - none of them gives the same results than DPP, unfortunately. I 
> believe Canon is playing games with us, they use their own "kitchen" and 
> don't give it away.
My understanding is that DPP (as any other RAW converter) is using CM
techniques just as part of the RAW conversion process. As long as we do
not know what they do (before or after CM transforms), the profiles are
difficult to use elsewhere. As you wrote, it is possible that some RAW
converters skip the standardised CM transform in full and do things
their own way completely...

The issue similarly applies to printing: the CM standards do not
describe all of the variables of the RGB printing process (dithering,
mixing light/dark inks, substitution of RGB data with CMYK, ...), which
affect colour appearance of the printout, hence it is the work of the
driver (known as the printing RIP). As long as the drivers do different
things, the ICC profiles cannot be mixed among the drivers.

Regards,

Milan Knizek
knizek (dot) confy (at) volny (dot) cz
http://www.milan-knizek.net - About linux and photography (Czech
language only)




More information about the Digikam-users mailing list