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

[edmund ronald]

Chris,

 I agree with everything you say.

 However at some point one needs to implement. And I respectfully
submit that a paradigm where one enters one set of (eg. colorimetric)
numbers that don't change, that get transmitted unchanged from
application to application, and that can if necessary have a set of
transforms appended, is a paradigm that will be more understandable to
developers than profiles.

 A developer can tell the system "write these (colorimetric)  colors
to the screen" and the system will make an educated guess how to do
that, if the developer wants to do something like adopt a different
white point he can say "change the white for these numbers, then write
them to the screen" etc. but he doesn't have to track the computation
or the display himself, the data stays as it is. And if the display
technology changes tomorrow, the app doesn't need to be rewritten.

 At the moment a developer needs to do things like workspace
conversions when reading a file, when displaying, when writing it etc,
so the developer needs to understand ICC, and inevitably
implementation errors will creep in, and also the data is getting
destructively modified.

Edmund

On Thu, Feb 3, 2011 at 10:35 PM, Chris Murphy <lists at colorremedies.com> wrote:
> 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
>