[Openicc] Linux CM ideology, was: meta data in test chart

[Chris Murphy]

The current paradigm is that profiles define a transformation. They are not really "device profiles" even though we keep calling them that. We do have a rather unfortunate problem that we don't have unmolested device data, and really we can't get back to it. The arguments that if profile builders followed a (convoluted difficult to understand) specification, and produced the profiles correctly that CMM vendors, and other developers or applications would be able to follow that same (non-self-defining, convoluted, difficult to understand) specification, and would be able to unwind the transformation back to the original data.

It's just not doable and I think the workflows, adoption rate, number of developers of ICC tools let alone actual usage of those profiles, especially that of v4, and PRMG non-adoption, prove this.

And the other thing is that there are some not so subtle aspects to how CMMs interpret the transformations. So you have another little finger in the pie that if you want specific results, you have to figure out and bake into your profile, which probably/maybe makes it "non-standard" or difficult to unwind back to measurement data again.

Now maybe there were good reasons in 1992 for baking in a transform into ICC device profiles, such as slow processors and limited memory. But I think the writing was on the wall in 1992 that this would not be the case forever, so I'm disappointed that the ICC v4 effort only strengthen the concept that the ICC device profiles aren't really descriptions of device behavior but transformations intended for device behavior.

So no I don't think those at the heart of Unix/Linux graphics are idiots either, but I agree with Graeme that they may very well just don't understand the problem, let alone the prescribed ICC solution to that problem.

I've always thought we kinda needed to mind meld with the geniuses behind ZFS and btrfs, that kind of clear abstraction and distillation of problems, where things belong, how you make something really basic yet complicate work really well at a foundational level seamless to users and to a great degree even developer. Totally not the same things, color management and file systems, but I think it would be very interesting to consider what it would look like if we started from scratch. And did it without the ICC as it currently exists now as well.

To move to something else requires Adobe, but Adobe isn't even on Linux. I don't know what their interest in this is. They've supported v4 in their CMM, and I think some scene referred profiles for video that are spec 4.2 based. I think that may be it, certainly no output device profiles that are v4. Moving to a new thing is a lot of work for a lot of people and whether we agree with the choices of others, a lot of other people have put in a huge amount of effort into v2 and v4. So I don't think we're going to get an effort like that again. And Microsoft put in a huge effort starting from scratch with WCS and now that's buried.

I do not think this leaves us in a very clear place. About as clear as it gets is that this is still an ICC v2 world. For better or worse.


Chris Murphy




On Feb 1, 2011, at 6:30 PM, edmund ronald wrote:

> On Wed, Feb 2, 2011 at 2:13 AM, Graeme Gill <graeme at argyllcms.com> wrote:
>> Jon Cruz wrote:
>>> 
>>> If you scroll down you should see a drop-down labeled "Play episode as :"
>>> 
>>> Choices I see are
>>> "Source — Flash Video (.flv)"
>>> "Web — Ogg Theora/Vorbis (.ogv)"
>>> "Portable (iPod) — MPEG-4 Video (.m4v)"
>>> 
>>> Then below that is a link for "Play in HTML5"
>> 
>> Yes, tried all that, none of the options worked for me with a version
>> of FireFox.
>> 
>>> I believe some people were using that info to be able to actually download
>>> the Ogg.
>> 
>> There's no direct links on the page though.
>> 
>> James Cloos did discover this, which worked after I downloaded it.
>> 
>> http://blip.tv/file/get/Linuxconfau-XAndTheFutureOfLinuxGraphics549.ogv?referrer=blip.tv&source=1&use_direct=1&use_documents=1
>> 
>> 
>> It seems from the video and the response to the question near the end,
>> that those at the heart of Unix/Linux graphics, still don't have much
>> of a clue about color management is, or why anyone would want it.
>> 
>> Graeme Gill.
> 
> I don't think they're idiots. I think Color Management has too much
> historical archeological accreted cr*p attached to it.
> 
> I mean, I've actually written real code from scratch dealing with
> color (a camera profiler in Matlab) and I still don't understand how
> print CMS works, or what goes into these geeky profile files.
> 
> It all reminds me of how we used to do pounds shillings and pence,
> bushels, ounces, pounds and stones, feet and yards and miles endlessly
> when I was in primary school, and then finally I went to a different
> school and we had metric!
> 
> Let me ask you guys a serious question - this is not a joke - don't
> you think that if the current CMS paradigm were reformulated and
> simplified (a bit like metric) people who design the OS tools would
> find it worthwhile to factor CMS in directly?
> 
> Edmund
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc