color management use-cases

simple monitor editing is almost trivial, you apply the input profile to
the monitor profile then edit and proceed

you can simulate a hard proof, Kodak did it with PCS100, and maybe
Prophecy and Design Master, Design Master was Eikonix before Kodak
bought it, Kodak bought Eikonix because it had a patent which made
scanners with filtration matching XYZ used in Design Master, Prophecy
and PCS100 were the Eikonix Kodak people's products, I didn't quite
understand that the print reference medium of the above products would
have to be made into an option for other media to get these products
from the pre-press markets in which they were successful to the
commercial photo labs that were interested in color management for
multi-purposing of images

one way to do a hard proof, you just use the proofer's profile and not
the monitor, use the proofer's space as the working space

one way if you want to simulate a hard proof on the monitor, you use the
"reverse" transform in the profile for the proofer, for instance
CMYK->XYZ, then XYZ of the proofer to XYZ of the monitor then the
"forward" transform of the monitor's profile, for instance XYZ->RGB,
this implies an XYZ working space, but you could pick a device space by
XYZ->device

a simulation of a press proof works the same way

a better hard proof simulation incorporates the press's profile, for
instance CMYK of press to XYZ of press to XYZ of proofer to XYZ of the
monitor to RGB of the monitor

all of the above should happen in the frame buffer of the graphics card
above the working space, for instance RGB of proof or simulation of
proof to RGB of working space, the working space should be held in
memory for editing under the buffer, the edits are made to the
simulation in the frame buffer then transferred to the working space and
eventually a standard storage space which should be a CIE delta E* space
like LAB or LUV for quality and purposing considerations

storage is a use-case too

I'm wondering if/when CIECAM will enter ICC

I'm also wondering if/when ICC and W3C will meet

 

maybe some errors here, I was an image systems engineer not a color
science, although I dabbled in the science when I got the chance and it
was one of my most enjoyable career things

correct me if I am wrong, but I think I got them all except for spot
colors, named colors, color palettes, etc.

also missed editing profiles

I do not know if ICC http://www.color.org has a white paper on use-cases
but they should

maybe I will make a free opensource imaging suite out of these, I know a
little about data-flow and object-oriented architecture, design and
programming

I know a little about bitmap creation and editing
I know a little about vector creation and editing
I know a little about page layout
I know a little about RIPs, renderers, etc.
I know a little about central storage/sharing

I just get stuck learning IDEs like netbeans and give up on regular
programming when I have to write a file library or something, I do
better with MATLAB, SAS, etc.

the Eikonix/Kodak group was going to make a central color server for
various people working on the same thing, they showed it in DRUPA once,
didn't have some things like account management, and various suite
considerations, just a bitmap thing, etc., or maybe it would have gone over

 

missed another

mixing palette colors on a palette

isn't as simple as Yuv, Yxy etc. color mixing, or other types

depends on the brush type, and where on the palette you are, towards the
edge you will have different colors than on the middle, colors will
differ along the edges of the brush, etc.

difficult, but important

might be easier if you temporarily let the mixing palette and brush be
vector types, then RIP it back to bitmap space afterwards