Preview RGB space versus RGB working space
Preview RGB space versus RGB working space
- Subject: Preview RGB space versus RGB working space
- From: Henrik Holmegaard <email@hidden>
- Date: Sat, 19 May 2001 10:03:11 +0200
Roger Breton <email@hidden> wrote:
Please correct me if I am wrong but aren't Monitor Profile only destined to
act as a "bridge" between whathever abstract RGB working space one choose to
use in Photoshop and the physical hardware of the monitor? Then, the concept
of R=G=B creating a neutral gray still holds *IN THE WORKING SPACE*. It's
just at the time of sending that R=G=B data to the monitor for physical
display that the Monitor Profile, whether LUT or Matrix-based, is called
upon and becomes a factor in color appearance management. Then, isn't it OK
if R is not G is not B, as long as whathever mix of RGB that gets send to
the monitor yields the best neutral on our colorimeter?
LUTs are good, but for device spaces, not for editing spaces.
Linocolor, and now also Photoshop 6, support LUT-based monitor
profiles. You can create LUT-based monitor profiles in ProfileMaker
and ViewOpen. The RGB working space is not the preview space, i.e. a
device space, but what for want of a better word has been called an
'RGB PCS', that is, a replacement for Lab/LCh as editing space. When
you are done with the pixel pushing in the RGB working space, the
question then is what you will do. Either you archive into your
matrix-based RGB working space or into a LUT-based RGB working space
like Joseph's full EktaColor space. I like the ECI idea of policing a
single matrix-based RGB working space throughout the workflow.
Ideally, everyone installs it, everyone uses it, all images go into
it, the numbers start to mean something for users, they start to
associate colors with those numbers, and so you get the same workflow
sociology as with Lab/LCh - well, almost the same.
What you don't get is profile independence, so if you loose the
definition of the pixels, you loose the workflow. Nor gamut
independence, since in converting into an RGB working space for long
term archiving and repurposing, the film gamut is cropped to that RGB
working space, and that is not the case if it stays in Lab where you
can take it to hifi color losslessly, come the day that we have file
format support for + 4 color workflows (and can compare film gamuts
and hifi press gamuts in 3D in the up and coming Seattle-based Disney
Studios of gamut comparisons -:)).
One other thing about RGB working spaces. Because PS5 presented a UI
that confused the old 'monitor setup' and the working space, people
have said, 'OK, I think I'll take AdobeRGB for my archiving, and I've
heard D50 is somehow better than D65, so I'll just change that, like
so, and click OK, and save out the same name 'AdobeRGB' instead of
'CustomRGB'. So I've created a better AdobeRGB.'
You can't create 'a better Lab' as a user. There are no buttons for
that - not anywhere I know of. If we come around to a situation where
applications work with ICC Lab D50 in 8 bit and 16 bit, then that's
one workflow problem less.
I think we need to ask application developers to be more frugal with
those buttons, and the RGB folks to come up with no more custom
working spaces than we already have far too many of in circulation
-:).