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

[Stefan Doehla]

You are absolutely right that this is not a trivial task - but I think it would be worth reconsidering the established approach which was targeting real-world problems of certain industries. Most people on this list are probably well aware of the problems of different gamuts etc. - but nevertheless, trying to teach CMS to the masses is still a challenging task and leaves plenty space for more books trying to illustrate the problems and solutions using the available tools.

It's the borked understanding of engineers trying to solve a problem in the perfect way with the result that a possibly complex task introduces a complex mechanism which in the end is completely understood only by the experts. It may seem naïve to request a simple thing which may still have some deficiencies - but in my opinion it would be worth starting with a clean sheet for Linux. The simple proposal should then be acceptable to both application developers, system developers and in the end hopefully hardware (which accomodates for its characteristics and environment itself, and which communicates its deviation from the 'standard').

Cheers
- Stefan


Am 03.02.2011 um 22:35 schrieb Chris Murphy:

> Simple for users and application developers means more complex infrastructure and heuristics to do the right thing in a variety of cases with many different kinds of products. Building this kind of complexity in the guts of a system takes  multiple personalities: color science, spec writing, programming, etc.
> 
> Color is so automatic to us, and we have all of these really cool adaptation features, and we're subject to lighting and surround effects in really interesting ways, but accounting for them is not easy. And so the desire to have "color-identical" anything is just really not possible even when we're talking about devices that have the same color gamut (which most do not, or more importantly not the same shape of gamut), unless the user really controls their environments. All of them. That's just not realistic. So if we accept the reality that environments are different and color gamuts are different, and we want to compensate for them as best we can instead of enforcing standard spaces and standard viewing environments, then the coding gets complex and then we have to have some assumptions anyway, and building UI's so the user can tell us they have a really bright viewing environment around their display but the print is going to be in a dark hallway.
> 
> Color identical is actually really difficult! The most difficult thing to do in all of color management is real soft proofing. It requires that the user alter their environment to match standards. Or it requires that they at least stabilize a non-standard environment, and substantially edit their profiles to account for that non-standard environment.
> 
> It's really not an easy juggling act.
> 
> 
> Chris
> 
> 
> On Feb 3, 2011, at 9:53 AM, Stefan Döhla wrote:
> 
>> Hi Edmund,
>> 
>> this discussion is very interesting to read and I agree with the simplicity argument.
>> 
>> What we really need is simplicity for successful color management. Anything else which solved problems for a certain vertical market has certainly been a step forward - but for the widespread color awareness a much simpler model is needed.
>> 
>> Having sRGB as the legacy agreement plus a new agreement on a data exchange format (not having transformations applied already) seems to me the only way forward. This is to some extent already happening, with data being ICC-tagged, but for widespread acceptance a good and really simple successor of the limited sRGB is - at least in my opinion - necessary. I see that this initially lacks proofing abilities - but most non-professionals just want things to be color-identical everywhere.
>> 
>> Cheers
>> - Stefan
>> 
>> Am 02.02.2011 22:23, schrieb edmund ronald:
>>> Max,
>>> 
>>> Thank you for this clarification.  I think everyone here appreciates
>>> the work you are doing, and the fact that you release your code as
>>> open source.
>>> 
>>> After reading and posting here for a while, It seems to me that even
>>> if the various specialists who post here manage to assemble a
>>> functional framework for Linux, OS-leve integration and support will
>>> remain haphazard as CMS is not really a priority for X, and
>>> application-level color management will also probably be incomplete
>>> and buggy because apps haven't got it now, and their authors are going
>>> to be faced with an over-difficult programming problem.
>>> 
>>> To me it seems that the situation with ICC1 and maybe now ICC2 is
>>> that it works reasonably for vertical markets, but does not offer a
>>> unified conceptual and programming model that is sufficiently simple
>>> as that non-specialised developers find themselves motivated to
>>> implement CMS, and capable of doing so.
>>> 
>>> If some other model would be offered that might be much simpler and
>>> unified even though less powerful, then maybe OS-level adoption would
>>> be easier to achieve. To put it bluntly, I believe that the idea of
>>> profiles and renderings which served as the foundation for Colorsync
>>> doesn't cut it in a general-purpose environment. It assumes too much
>>> understanding on the part of non-specialist developers.
>>> 
>>> I would suggest that writing an "absolute" (colorimetric) color to a
>>> window or a printer might make more sense because it would then be the
>>> responsibility of the OS to make sure that the write-through to the
>>> physical device actually has some acceptable semantics; This would be
>>> a simplification which both the graphics systems designers and
>>> applications designers could relate to.
>>> 
>>> Edmund
>>> 
>>> On Wed, Feb 2, 2011 at 9:11 PM, Max Derhak<max.derhak at onyxgfx.com>  wrote:
>>>> Hi,
>>>> 
>>>> As I'm on the ICC AWG working with others on ICC.2 at the moment I'd
>>>> like to pipe in a bit here.  We are definitely open to outside input.
>>>> Before I say anything else though, let me make it perfectly clear that
>>>> ICC.2 is not meant as a replacement for ICC.1.  If you are happy with
>>>> ICC.1 then stick with it.  If you are unhappy, then we can talk about
>>>> ICC.2 which is really meant to address areas (though not all) that ICC.1
>>>> does not address well.
>>>> 
>>> _______________________________________________
>>> openicc mailing list
>>> openicc at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/openicc
>> 
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc