[Openicc] Fwd: Re: Krita color adjusting

[Casper Boemann]

On Tuesday 14 June 2005 11:11, Jan-Peter Homann wrote:
> Hello Caspar, hello list
>
> Today, I want share some ideas about coloradjustment and colormanagement
> with you. As you explainend to me in private mail, your goal is a
> coloradjustment, which is as much as possible independent from the
> actual colorspace /colormodel you are actually using in Krita.
>
> As I explained to you, my goal is to use abstract-profiles or
> devicelink-profiles as universal exchange format for color-adjustments.
> In this case, a coloradjustment could be applied to all applications,
> which use lcms or argyllcms.

Won't it be a problem that you can't recreate the way the profile was
 created?

> Workingspace, Adjustmentlayer, Simulationspace, Outputspace
> ------------------------------------------------------------
> Colormanagement makes it possible, to work in very complex color
> environments. I will first start with easier ones, and go later to the
> more complex versions.
>
> 1) The easiest model: workingspace and the outspace.
> ----------------------------------------------------
> The workingspace can be e.g. sRGB and the outputspace could be the
> colorspace of the monitor or the printer.
> All coloradjustments are made directly in the workinspace. For getting
> the right color at the monitor, the CMM converts constantly from
> workingspace to the monitor-colorspace.
> After finishing the work, the data can be saved directly, and the
> profile of the workingspace is embedded. For printing the color is
> converted from workingspace to printer-colorspace.
> If an file should be used in another workingspace, it is converted to a
> new workingspace. E.g. the sRGB data is converted to SWOP (CMYK).
> Now SWOP is the new workingspace, but the overall configuration:
> - workingspace->monitorprofile
> - workingspace->printerprofile
> - coloradjustments directly in workingspace
> - Save with embedded workingspace profile
> stay always the same

this is the model we use currently

> 2) Workingspace, Simulationspace, Outputspace
> ----------------------------------------------
> This is a little bit more complex.
> The workingspace is mostly a widegamut RGB-colorspace or Lab/LCH
> colorspace. The goal is to work on color independent from the later
> output intention.
> Color-adjustments, retouches and composings are made in the workinspace
> RGB or Lab/LCH.
> During work, it is possible to simulate different colorspaces for the
> intended output.
> The profilechain is:
> workingspace-simulationspace-monitorprofile
> workingspace-simulationspace-printerprofile
> workingspace-Save with transformation and embedding the simulation
> colorspace

Pretty smart idea that I thought of myself, but it more or less requires that
we decide on a working space once and for all?
I thought that XYZ would be a good workingspace, but we have a problem with
our natural painting then. So in order to stay flexible in accomodating _any_
colorspace I don't think this is the way to go.

> 3) Workingspace, adjustmentlayer, outputspace
> ------------------------------------------------
> Caspar, if I understand you right, your plan is to use an abstract layer
>   for coloradjustments, independent from the actual workingspace. This
> could be realized with abstract profiles.

Well I both intend to have adjustmentlayers, and to be able to adjust
 directly in the workingspace.

> But be aware, that your workinspace must be a valid ICC-profile.
> If you are using special multichannel workingspaces for simulation of
> naturl-painting, you have to calculate a multichannel ICC-profile.
> For doing this, you have to build a model for opacity, mixing of the
> channels etc. defined in the Lab colorspace.
> The you have to build a matrix from different mixtures of the
> devicecolors with their Lab-equivalents. From this matrix, you can
> calulate a multichannel-profile, which can be used as workingspace for
> multichannel colormodels.
>
> Another way are RGB-based models for simulation of natural-paintings
> In this case, you have a formula, which are converting the colors from
> your natural-painting-model to a RGB-workingspace.
> In this case, you have to take care, what RGB-workinspace you are using.
> If you use AdobeRGB instead sRGB, you will get much more saturated
> colors on the monitor. If you use photogamutRGB - wich is part of the
> standard profiles installer from Kai - you will get a comparable result
> to sRGB, but the primaries and secondaries are orientated on printable
> colors and are very similar to the reference medium gamut of the ICC.
> Photogamut is may be one of the best possible RGB-workinspaces for
> natural-painting modeling.
>
> If you made a decision for an RGB-workinspace, you can use it as an
> intermediate step to build a mulitchannel-profile. A matrix
> (ASCCI-Numbers) of the devicecolors of your natural-painting model are
> first converted to RGB and from there to Lab ASCII numbers.
>  From the resuting matrix
>
> ASCII-File
> Device-colors->Lab-colors
>
> you calculate the multichannel profile.
>
> So the krita-team has to made following decision:
> - should there be a Master RGB-workingspace ?

possibly for the natural painting model, but not in general. I think that
should be a per colormodel decission.

> - If yes, how should different workinspaces be evaluated ?

I don't understand

> - Should multicolor-profiles for natural-painting be implemented ?
>
> If you go the multicolor-way, it makes sense to concentrate on
> coloradlustment based on abstract profiles

This is the way we go in general. For some colormodels (like natural paining)
we might convert to an intermediate colorspace and from there use abstract
profiles.

If it is possible to make a direct transform from the natural colormodel to
Lab then I'm sure we would do that, but our option must be open

> If you concentrate on a Master RGB-workinspace, it makes more sense to
> implement RGB-based coloradjustment.

since we won't limit ourselves to a single workingspace, I don't see this as
an option.

--
best regards / venlig hilsen
Casper Boemann