[OpenICC] Oyranos APIs update

[Kai-Uwe Behrmann]

Hello,

Am 15.09.05, 14:19 +0200 schrieb Jan-Peter Homann:

> Hello Kai-Uwe, hello list
> 
> I want to give some comments from the view of an colormanagement consultant.
> 
> First we need something like "colormanagement-policies" and the possibility to
> save/export/import a complete "colormanagement-setting" wich includes the
> profiles and the colormanagement policies.

I will look at saving and reloading of configurations.

> The structure of the colorsettings / colormanagement-policies in the Adobe
> Creative Suite 2, are fine for graphics arts people with one critical point.
> 
> Actually all the big players don´t distinguish the settings for the
> RGB-workingspace and the settings for untagged RGB-data.
> In such environments, the profile for the RGB-workingspace is automaticly
> assigned for untagged RGB-data.
> 
> According W3C recommendations and IEC 61699 for consumer-devices, sRGB is
> common for untagged RGB-data.

This dont touches data exchange between applications on different systems, 
except the WWW.

> Assigning a large-gamut RGB-workingspace to untagged sRGB-data results to
> heavy colorshifts.

Then we would distinguish between RGB files coming in from:
a) the internet -> sRGB
b) elsewhere -> OY_DEFAULT_RGB_INPUT_PROFILE

+ an RGB Workingspace for conversions during manipulation (if allowed 
through the policy). OY_DEFAULT_WORKSPACE_RGB_PROFILE

The internet browser should attach the sRGB profile during download.
Is this realistically thought? Can we expect morzilla and konqueror and co 
do like we suggest?

This suggestion could be included into a set of rules, wherein the 
behaviour of applications is described regarding colour spaces and 
profiles.

> So it would make sense to make a new default profiles field in Oraynos:
> - Untagged RGB-data. The name "Workspace Profile" should renamed to "RGB
> Workspace-Profile" CMYK Input Profile should be renamed to "CMYK Workspace
> Profile" Espcialy for applications like e.g. Scribus or Inkascape, such
> profile describes the appereance of CMYK-colors generated by the user and not
> only for placed content.

Yes, see above.
 
> For device-profiles, I think, it is better and much more transparent to
> configure the profiles in the applications for image aquisition or printing.
> 
> For a more clear user-interface it would make sense to hide the profiles for
> Lab and XYZ.

Depending on the policy yes. Generally it is more straightforward to 
concentrate on an system, which is based on device independent colour 
description, rather than RGB. The device to device jumping method inside 
the colour data itself is an workaround not the solution.

> A new part of oraynos should be named "colormanagement-policies" with e.g.
> following options:
> 
> image-aquisition:
> - embedd source-profile
> - convert to RGB Workspace (default)
> - convert to CMYK Workspace
> 
> profile dialogues:
> show dialogues during
> - opening untagged data
> - opening data with profile mismatch
> - copy and paste with profile mismatch
> - dont show profile dialogues

Thats nearly what is preferable in CinePaint. Sounds allmost reasonable 
at least to me.
The second point is an non conversion policy? Whats happens with the 
profile in this situation?

> layout and graphics applications:
> - preserve embedded profiles for placed RGB-files
> - preserve embedded profiles for placed CMYK-files
> - preserve CMYK-values for placed CMYK-files
> - convert all placed files to RGB workingspace
> - convert all placed files to CMYK workingspace

Thats more about handling mixed mode documents -> Scribus, Adobe, Inkscape 
...

> printing:
> - do colormanagement in the printer driver (default)
> - do colormanagement in application
> - rendering intent

On source of uncertainess is the behaviour of untagged data. Jan-Peter you 
brought this allready up. 
My point of view is to not change RGB data if untagged.
An application, which is not able to tag itself, or uses helper, dont 
obtains CMS support.
This sound a little bit hard but would force to use the basics of colour 
management after an period of transition. 
The concern is about files ready to print or display without further 
colour conversion.
They would allways be missinterpreted in a system there CMS unaware 
applications are pressed into an default behaviour. As well data 
exchange across computers is undefined for untagged data. This must be 
clear.


> For every Oraynos colorsetting should be a description for the enduser.
> If an application makes use of an Oraynos colorsetting, it should present this
> description to the user and a link/button to open Oyranos.

Well, as some applications allready have implemented some of the above 
described settings. Whats the opinion about completely removing these 
settings or leaving them as exception inside the application preferences?
 
> For the LINUX apps targeting the graphics arts market, it would make sense to
> deliver default Oyrans settings, which are comparable to standard-settings in
> Adobe Creative Suite 2 concerning standard-profiles and colormanagement
> policies.

Sorry, I dont have Adobe Creative Suite 2 to check. Can someone help 
with an manual or borrow the software for some days, to look for?

> :-) Jan-Peter

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name


> Kai-Uwe Behrmann wrote:
> > Hi,
> > 
> > the unstable Oyranos APIs documentation is online. See:
> > <www.oyranos.org>
> > 
> > stable considered APIs:
> > o Default Profiles API
> > o Path Names API
> > o Profile Lists API
> > o Profile Handling API - as small as it is currently
> > o Monitor API - except the monitor information handling
> > 
> > 
> > unstable API:
> > o Device Profiles API
> > 
> 
> 
> 
> -- 
> --
> 
> homann colormanagement ------ fon/fax +49 30 611 075 18
> Jan-Peter Homann ------------- mobile +49 171 54 70 358
> Kastanienallee 71 ------- http://www.colormanagement.de
> 10435 Berlin --------- mailto:homann at colormanagement.de
>