Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Digital Photography > why device independent color?

Reply
Thread Tools

why device independent color?

 
 
nospam
Guest
Posts: n/a
 
      01-25-2014
In article <(E-Mail Removed)>, Eric Stevens
<(E-Mail Removed)> wrote:

> >> > what is needed is a colour managed workflow, with the image and each
> >> > device along the way having a profile.
> >> >
> >> that's how you get the profiles

> >
> >no, you get the profiles by running the appropriate profiling software.
> >
> >what the software does internally doesn't matter. users do not need to
> >understand all the math behind it to be able to use it.
> >
> >what matters is does the user get what they expect, and the answer is
> >yes.

>
> You are missing the point of Dale's original comment:
>
> "you need to convert the device colors through device independent
> color space like XYZ,CIELAB,CIELUV".


given that users do not have to do that, what exactly am i missing?

the *computer* might do it internally (or it might not), depending on
what needs to be done to produce the result the user wants.

the user does not need to worry about that nor do they nee to know what
any of that means.

what matters is if they get the expected results, and with a colour
managed workflow, they do.
 
Reply With Quote
 
 
 
 
nospam
Guest
Posts: n/a
 
      01-25-2014
In article <(E-Mail Removed)>, Eric Stevens
<(E-Mail Removed)> wrote:

> >> >> >what they need to do is use a colour managed workflow and the computer
> >> >> >takes care of the details.
> >> >> >
> >> >> >if you choose a different printer, pick the relevant profile and
> >> >> >whatever conversions are necessary are done automatically.
> >> >> >
> >> >> >once again, let the computer do the work.
> >> >>
> >> >> But the computer has to have some standards against which it can
> >> >> determine the meaning of the colour profile. Otherwise its a bit like
> >> >> saying to your tailor I want a 197 chest, a 132 waist and a leg of
> >> >> 106. At which point your tailor will say "Huh! Waddaya mean?".
> >> >
> >> >the computer knows how to convert it. the authors of the profiling
> >> >software need to understand the math to write the software to do the
> >> >conversions. that's about the extent of it.
> >>
> >> Here we go again. It's not about what the computer knows or the
> >> computer can do for the user.

> >
> >of course it is.
> >
> >> It's about the definition of colour
> >> spaces such as sRGB, and whatever else it is you have snipped, for
> >> which you need an underlying reference system such as "XYZ, CIELAB,
> >> CIELUV".

> >
> >no it isn't.

>
> Yes it is. Please read the subject of the thread and Dale's article
> which started it. If you want to talk about something different please
> go away and start another thread.
> >
> >the user wants as close a match as possible, given the limits of a
> >device. that requires a colour managed workflow.
> >
> >they don't need to know the math as to how it works.

>
> Whoever said they did?
> >
> >> >the end users do not need to understand any of it, other than how to
> >> >use profiles in a colour managed workflow.
> >>
> >> True, but you are changing the subject.

> >
> >not at all.

>
> Read Dale's article.


i did, and it's wrong.
 
Reply With Quote
 
 
 
 
Dale
Guest
Posts: n/a
 
      01-25-2014
On 01/24/2014 11:18 PM, Eric Stevens wrote:
> On Fri, 24 Jan 2014 22:11:52 -0500, nospam <(E-Mail Removed)>
> wrote:
>
>> In article <(E-Mail Removed)>, Eric Stevens
>> <(E-Mail Removed)> wrote:
>>
>>>>>> what is needed is a colour managed workflow, with the image and each
>>>>>> device along the way having a profile.
>>>>>>
>>>>> that's how you get the profiles
>>>>
>>>> no, you get the profiles by running the appropriate profiling software.
>>>>
>>>> what the software does internally doesn't matter. users do not need to
>>>> understand all the math behind it to be able to use it.
>>>>
>>>> what matters is does the user get what they expect, and the answer is
>>>> yes.
>>>
>>> You are missing the point of Dale's original comment:
>>>
>>> "you need to convert the device colors through device independent
>>> color space like XYZ,CIELAB,CIELUV".

>>
>> given that users do not have to do that, what exactly am i missing?

>
> You are missing the point that this dicussin is confined to camera
> users.
>>
>> the *computer* might do it internally (or it might not), depending on
>> what needs to be done to produce the result the user wants.
>>
>> the user does not need to worry about that nor do they nee to know what
>> any of that means.
>>
>> what matters is if they get the expected results, and with a colour
>> managed workflow, they do.

>
> Good. We agree on that. Please now go away and come back when you
> accept that colour managed work spaces (with profiles etc) requires
> "device independent color space like XYZ,CIELAB,CIELUV".
>
> Otherwise it's like you giving a tailor the dimensions for a suit in
> units of measurement for which he has no definition.
>


I think the value of device independent color is underestimated

sure, light sources and filtration can make it easier, Eikonix/Kodak
has/had a patent of filtration for scanners and maybe cameras that
matched XYZ which makes it a lot easier, you could probably use a matrix
and 1D LUT instead of a 3D LUT, ICC can accommodate both math constructs

but I see a problem with digital cameras

chrome film/scanners were easy for device independent workflows, you
only needed to match the chrome

with a digital camera you have to match the scene, appearance as opposed
to color considerations come into play, like white balance

I have heard people are using the RAW camera files without the white balance

I have heard Kodak has a patent on how to characterize cameras without a
target

targets are a hassle for photographers

I don't think this is going to be resolved until camera manufacturers
make profiles for their cameras instead of using sRGB, ProPhotoRGB, etc.

they could to this with information of sensor sensitivity, sensor
filtration, etc., and stuff it into an ICC profile

--
Dale
 
Reply With Quote
 
Dale
Guest
Posts: n/a
 
      01-25-2014
On 01/24/2014 11:16 PM, nospam wrote:
> In article <(E-Mail Removed)>, Eric Stevens
> <(E-Mail Removed)> wrote:
>
>>>>>>> what they need to do is use a colour managed workflow and the computer
>>>>>>> takes care of the details.
>>>>>>>
>>>>>>> if you choose a different printer, pick the relevant profile and
>>>>>>> whatever conversions are necessary are done automatically.
>>>>>>>
>>>>>>> once again, let the computer do the work.
>>>>>>
>>>>>> But the computer has to have some standards against which it can
>>>>>> determine the meaning of the colour profile. Otherwise its a bit like
>>>>>> saying to your tailor I want a 197 chest, a 132 waist and a leg of
>>>>>> 106. At which point your tailor will say "Huh! Waddaya mean?".
>>>>>
>>>>> the computer knows how to convert it. the authors of the profiling
>>>>> software need to understand the math to write the software to do the
>>>>> conversions. that's about the extent of it.
>>>>
>>>> Here we go again. It's not about what the computer knows or the
>>>> computer can do for the user.
>>>
>>> of course it is.
>>>
>>>> It's about the definition of colour
>>>> spaces such as sRGB, and whatever else it is you have snipped, for
>>>> which you need an underlying reference system such as "XYZ, CIELAB,
>>>> CIELUV".
>>>
>>> no it isn't.

>>
>> Yes it is. Please read the subject of the thread and Dale's article
>> which started it. If you want to talk about something different please
>> go away and start another thread.
>>>
>>> the user wants as close a match as possible, given the limits of a
>>> device. that requires a colour managed workflow.
>>>
>>> they don't need to know the math as to how it works.

>>
>> Whoever said they did?
>>>
>>>>> the end users do not need to understand any of it, other than how to
>>>>> use profiles in a colour managed workflow.
>>>>
>>>> True, but you are changing the subject.
>>>
>>> not at all.

>>
>> Read Dale's article.

>
> i did, and it's wrong.
>


the way things are NOW, photographers and lab techs/engineers have to
know about the making of profiles, once device/driver manufacturers make
profiles for their devices, it will be more like you are getting at, it
shouldn't matter to the user, but sometimes a user might want to
make/edit his own profiles

this leads to measurement instrumentation

when I worked at Kodak we had spectroradiometers, colorimeters etc.,
that cost over $100,000

the software I see now is for instruments like X-Rite and MacBeth
levels, works okay for software like Kodak's ColorFlow where you are
actually creating an edited profile, but I think the ICC needs to get
more influences to device/driver manufacturers

someone needs to have the high priced instruments

then again there is such a thing as "good enough", especially when
applied to consumer imaging, television is trying to get into the high
quality professional markets though

--
Dale
 
Reply With Quote
 
me
Guest
Posts: n/a
 
      01-25-2014
On Sat, 25 Jan 2014 02:10:23 -0500, Dale
<(E-Mail Removed)> wrote:

>but I see a problem with digital cameras
>
>chrome film/scanners were easy for device independent workflows, you
>only needed to match the chrome
>
>with a digital camera you have to match the scene, appearance as opposed
>to color considerations come into play, like white balance
>
>I have heard people are using the RAW camera files without the white balance
>
>I have heard Kodak has a patent on how to characterize cameras without a
>target
>
>targets are a hassle for photographers
>
>I don't think this is going to be resolved until camera manufacturers
>make profiles for their cameras instead of using sRGB, ProPhotoRGB, etc.
>
>they could to this with information of sensor sensitivity, sensor
>filtration, etc., and stuff it into an ICC profile



Really, I've heard people have seen UFOs. Instead of repeatedly laying
out your perceived problem (real or not), why not lay out the solution
other than I heard, or all you have to do is...

How exactly do you make a single profile which fits an infinite
variation of lighting? If you don't characterize the lighting you
don't have enough information to solve the problem at hand.
 
Reply With Quote
 
nospam
Guest
Posts: n/a
 
      01-25-2014
In article <(E-Mail Removed)>, Dale
<(E-Mail Removed)> wrote:

> the way things are NOW, photographers and lab techs/engineers have to
> know about the making of profiles, once device/driver manufacturers make
> profiles for their devices, it will be more like you are getting at, it
> shouldn't matter to the user, but sometimes a user might want to
> make/edit his own profiles


making a profile is easy. just run the software.

what photographers and techs don't need to know is the math behind the
conversions and everything else about colour management.

> this leads to measurement instrumentation
>
> when I worked at Kodak we had spectroradiometers, colorimeters etc.,
> that cost over $100,000
>
> the software I see now is for instruments like X-Rite and MacBeth
> levels, works okay for software like Kodak's ColorFlow where you are
> actually creating an edited profile, but I think the ICC needs to get
> more influences to device/driver manufacturers
>
> someone needs to have the high priced instruments


no they don't.

the low priced colour pucks work exceptionally well, and since they are
affordable by just about anyone, they actually get used.

> then again there is such a thing as "good enough", especially when
> applied to consumer imaging, television is trying to get into the high
> quality professional markets though


today's low price products are *better* than the overpriced stuff you
may have had long ago.
 
Reply With Quote
 
nospam
Guest
Posts: n/a
 
      01-26-2014
In article <(E-Mail Removed)>, Eric Stevens
<(E-Mail Removed)> wrote:

> It still comes back to your original point that you can't talk
> meaningfully about device colour profiles unless you have a recognised
> colour space to measure them against. Hence the need for device
> independent color spaces like XYZ,CIELAB,CIELUV. I suppose you could
> of course do it all in terms of Angstrom units.


sure, but users need not concern themselves with any of that.

all they need to do is adopt a colour managed workflow.
 
Reply With Quote
 
PeterN
Guest
Posts: n/a
 
      01-26-2014
On 1/25/2014 9:10 PM, Eric Stevens wrote:
> On Sat, 25 Jan 2014 19:42:30 -0500, nospam <(E-Mail Removed)>
> wrote:
>
>> In article <(E-Mail Removed)>, Eric Stevens
>> <(E-Mail Removed)> wrote:
>>
>>> It still comes back to your original point that you can't talk
>>> meaningfully about device colour profiles unless you have a recognised
>>> colour space to measure them against. Hence the need for device
>>> independent color spaces like XYZ,CIELAB,CIELUV. I suppose you could
>>> of course do it all in terms of Angstrom units.

>>
>> sure, but users need not concern themselves with any of that.

>
> Who is talking about that, apart from you?
>>
>> all they need to do is adopt a colour managed workflow.

>
> How do you set up a colour managed work flow without standards against
> which you can calibrate it?
>

Interested people want to know.

--
PeterN
 
Reply With Quote
 
Martin Brown
Guest
Posts: n/a
 
      01-27-2014
On 26/01/2014 02:08, Eric Stevens wrote:
> On Sat, 25 Jan 2014 14:01:02 -0500, nospam <(E-Mail Removed)>
> wrote:
>
>> In article <(E-Mail Removed)>, Dale
>> <(E-Mail Removed)> wrote:
>>
>>> the way things are NOW, photographers and lab techs/engineers have to
>>> know about the making of profiles, once device/driver manufacturers make
>>> profiles for their devices, it will be more like you are getting at, it
>>> shouldn't matter to the user, but sometimes a user might want to
>>> make/edit his own profiles

>>
>> making a profile is easy. just run the software.
>>
>> what photographers and techs don't need to know is the math behind the
>> conversions and everything else about colour management.

>
> Something has to know and ultimately it boils down to people having to
> know.


Yes. But only a handful of people who work on the design of imaging
systems actually need to understand the details of the mathematics that
underpins moving between colour spaces reliably. The end user merely
needs to be able to see clearly what parts of his image cannot be
rendered accurately on the final destination medium and preview what it
will look like after the compromises are made for gamut capability.
>>
>>> this leads to measurement instrumentation
>>>
>>> when I worked at Kodak we had spectroradiometers, colorimeters etc.,
>>> that cost over $100,000
>>>
>>> the software I see now is for instruments like X-Rite and MacBeth
>>> levels, works okay for software like Kodak's ColorFlow where you are
>>> actually creating an edited profile, but I think the ICC needs to get
>>> more influences to device/driver manufacturers
>>>
>>> someone needs to have the high priced instruments

>>
>> no they don't.

>
> Well where does the calibration standard come from?


You don't need that many of the high end instruments - modern simple
color measurement devices are now surprisingly good. The dye
manufacturers and printer/display makers labs will need such kit to
characterise the properties of new inks and papers or OLED/plasma/LCD
but end users can get by with very modest colorimetry.
>>
>> the low priced colour pucks work exceptionally well, and since they are
>> affordable by just about anyone, they actually get used.

>
> How could you know they work exceptionally well if you didn't have
> standards against which you can test them?


Photograph a few colour paint sample charts and then do a calibrated
workflow then compare the resulting print against the original - as a
concrete example. The human eye is very good at spotting small
differences in hue - especially on near flesh tones.

Heck this is already so well established that there is paint
manufacturer software to allow you to photograph a small test chart with
a hole in it for the unknown target colour on your mobile phone. Email
it to the paint maker and they will send you back a mix formula to match
it that can be taken to your nearest DIY store and works.

It isn't that long ago that individual batches of paint with nominally
the same colour formulation could have radically different properties.

American NTSC TV used to amuse Europeans because the newscaster would
drift between having ghoulish green and surreal purple flesh tones or
else be clamped to an unearthly pale orange by the flesh bodger. I
always assumed it was an inherent limitation of NTSC until I saw the
Japanese domestic implementation of it which works flawlessly.
>>
>>> then again there is such a thing as "good enough", especially when
>>> applied to consumer imaging, television is trying to get into the high
>>> quality professional markets though

>>
>> today's low price products are *better* than the overpriced stuff you
>> may have had long ago.

>
> How can you know that, without using even better and higher priced
> stuff to test and calibrate them?


I was involved in some of the very early dyesub printing in Japan. They
kept separate colour profiles for printing souvenir images of visiting
VIPs - Westerners and Japanese. These were largely subjective and
neither group liked seeing a neutral balanced version of their portrait!

When a westerner was due one of us would be photographed and printed to
check the calibration. A Westerner printed on the Japanese setting would
look pink like they were drunk and a Japanese person printed on the
Westerner setting would look jaundiced. Neither setting represented true
calibrated neutral reality but the "customers" didn't like reality!

--
Regards,
Martin Brown
 
Reply With Quote
 
Martin Brown
Guest
Posts: n/a
 
      01-27-2014
On 24/01/2014 23:47, Eric Stevens wrote:
> On Fri, 24 Jan 2014 12:13:47 -0500, nospam <(E-Mail Removed)>
> wrote:
>
>> In article <(E-Mail Removed)>, Dale
>> <(E-Mail Removed)> wrote:
>>
>>>>
>>>> what is needed is a colour managed workflow, with the image and each
>>>> device along the way having a profile.
>>>>
>>> that's how you get the profiles

>>
>> no, you get the profiles by running the appropriate profiling software.
>>
>> what the software does internally doesn't matter. users do not need to
>> understand all the math behind it to be able to use it.
>>
>> what matters is does the user get what they expect, and the answer is
>> yes.

>
> You are missing the point of Dale's original comment:
>
> "you need to convert the device colors through device independent
> color space like XYZ,CIELAB,CIELUV".


But that is clearly not true!

It is a lot more convenient to convert to a device independent colour
space and from there to whatever output medium you want to use because
the number of profiles need for N different image sources and M
destinations is limited to N+M colour profiles.

But you could with a *lot* more work compute direct colour profiles for
every possible combination of source and destination N*M. In the early
days when N was about 3 and M was about 4 that was what happened.

It may still make a lot more sense to store the original image in the
colour space where it was measured and only ever compute the device
independent form as a hidden step on the way to the output device.

You lose a bit to rounding errors in every colourspace conversion.
(with a handful of exceptions that are exactly invertable)

--
Regards,
Martin Brown
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why is there no platform independent way of clearing a terminal? Daniel Fetchinson Python 49 08-06-2010 02:42 AM
Changing font color from current font color to black color Kamaljeet Saini Ruby 0 02-13-2009 04:58 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
C++ object for Device Independent Bitmaps David Cox C++ 5 08-01-2005 02:12 AM



Advertisments