RE: Repurposing HSV on SGIs
RE: Repurposing HSV on SGIs
- Subject: RE: Repurposing HSV on SGIs
- From: Jeff Harmon <email@hidden>
- Date: Sat, 10 Feb 2001 00:13:35 -0800
>
> So the files I'll be getting exported to me will be
>
> basically untagged RGB.
>
>
Right, an assumed source CMYK profile doesn't work when the source is
>
RGB. Then it's back to figuring out what standard monitor phosphor
>
set the application uses for its internal RGB since it doesn't use
>
actual monitor phosphors measured by a colorimeter. Standard monitor
>
phosphor sets are built into software calibrators, for instance.
I would think it probably uses LAB internally and then sends signals to the
monitor, defined by what the monitor can show, phosphors and all. I'm sorry
Henrik, I really am trying to understand! It seems to me it's probably not
about an internal RGB with abstract phosphor sets, but LAB chucked through
the monitor's physical limits. Then again I don't understand all the steps
involved as you do!
And why do you pinpoint the phosphor set? Why not the white point and gamma
as well? (Actually the only thing a user can designate in the app is the
gamma, in "Monitor Preferences.") I would assume it was making assumptions
there as well. I'm in conversation with the app engineers, but haven't
reached the color scientist there yet.
>
In this situation where all the monitors will be off by definition,
>
maybe a color server that does a global color correction with an
>
abstract profile inserted between assumed source RGB and printer CMYK
>
might be useful.
I'm being hired right now to repurpose imagery from the pre-existing set-up.
Later I'll be setting it up differently, with an ICC-savvy RIP,
transitioning off SGI to Windows as well!
>
> separated in-RIP blindly, with no specifically defined input or output
>
> profiles/spaces.
>
>
Well, if there is a RIP then the printer relies on PostScript, and if
>
there is PostScript there is a default 'device color' matrix
>
conversion from RGB to CMYK with hardcoded black generation (level 1,
>
level 2 and level 3). A RIP level 2 and above also has CRDs.
>
I'd think the IRIS has a RIP and the Epsons don't. To make things
>
work there should be a RIP in front of the Epsons, too.
Yes, the RIPs in between all of them are made by ColorByte. And they have
virtually NO visible color controls; it's all behind the scenes. I think
the most important thing for me to figure out is what they are assuming
about the RGB upstream, obviously. Easier said than done.
>
BTW there used to be negotiations between Kodak and SGI on
>
implementing the Kodak ICC CMS in Irix. If I remember rightly Todd
>
Newman was the SGI representative to the ICC at the time. Maybe
>
nothing happened, I'm not sure.
I think nothing happened. I'll check into it.
Thanks for taking the time to share your knowledge and experience!
----------------------------
j e f f h a r m o n
director
colorhythm
1526 woolsey street
berkeley ca 94703
510.647.3689
email@hidden
http://www.colorhythm.com
----------------------------