[Openicc] Devicelink profiles and accompanying metadata

[Ann L McCarthy]

the metadataTag can be defined by you to have the contents useful for 
devicelink profiles. 
For example, as listed below -- create a metadataTag name for each of the 
decisions that
go into a devicelink:
source rendering intent, 
destination rendering intent,
... and so on.

Best regards,
Ann McCarthy
Imaging Systems R&D
Lexmark Imaging Solutions Division
Lexmark International, Inc.






Kai-Uwe Behrmann <ku.b at gmx.de> 
Sent by: openicc-bounces at lists.freedesktop.org
04/05/2010 04:15 PM

To
"Alastair M. Robinson" <blackfive at fakenhamweb.co.uk>
cc
OpenICC Liste <openicc at lists.freedesktop.org>
Subject
Re: [Openicc] Devicelink profiles and accompanying metadata






Am 05.04.10, 17:09 +0100 schrieb Alastair M. Robinson:

> Hi :)
>
> Kai-Uwe Behrmann wrote:
>
>> They would become visible in the general ICC profile path.
>> How does you think software can select these profiles? What shall the 
UI
>> show to the user or how can the selection happen automatic?
>
> Well these issues are the reason for my question - I wanted to know
> whether anyone else had given it any thought, and whether there was any
> consensus on the right way to handle devicelinks, before putting too
> much time into it myself.

It would be nice to have.

> I can only speak for my own software, but currently I display a
> Descriptive name for a profile if possible, and the filename if not.
> The ProfileSelector widget used in PhotoPrint, CMYKTool, etc., has a
> flag which the application can use to choose whether or not devicelinks
> will be included in the list of profiles.

After thinking a bit about. A UI, profile selector, would need to know 
about the input and output profiles. It will be difficult to see rendering 

intent, bpc, proofing profile ...  Maybe thats where the Metadata tag 
would come nice into play.

Oyranos does its transform caching as device links as well. Maybe 
shared meta data tag semantics would make sense. Then apps can see cached 
colour transforms in /usr/var/color/icc/devicelink/ or something like 
that.

> I don't know how good or otherwise the support for Devicelinks is in
> other software, or how much havoc their appearance in standard search
> paths would cause - would it be better to create a new directory for
> these (say, XDG_DATA_HOME/color/devicelink or
> XDG_DATA_HOME/color/icc_devicelink) or just cache them privately?

It depends how well specified the meta data are and if they can be used 
for something. If not it makes less sense to appear in the profile path.

>> Consider the 'psid' tag?
>
> The profiles I intend to create will be created using the ArgyllCMS
> command-line utilities - so I guess I'd need to write some kind of
> "injector" utility to add such a tag after the profile's created (unless
> there's some utility already out there that I don't know about yet?).
> Other than that, it sounds like an ideal solution.

Oyranos writes psid. Grep for icSigProfileSequenceIdentifierType to see 
the code. Be careful with the md5 hash sum. Its ICC specific.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

_______________________________________________
openicc mailing list
openicc at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20100405/b57f0f07/attachment.htm>