<br><font size=2 face="sans-serif">Hi Jan-Peter and all,</font>
<br>
<br><font size=2 face="sans-serif">I would agree that it needs to be a free choosable color space that is independent of</font>
<br><font size=2 face="sans-serif">scanner, camera, monitor, types of RGB spaces and that is also independent of any</font>
<br><font size=2 face="sans-serif">particular CMYK. Note that Adobe RGB is a monitor type of RGB even though it is </font>
<br><font size=2 face="sans-serif">wide gamut.</font>
<br>
<br><font size=2 face="sans-serif">Yes - I was thinking that a proofing color space would be an intermediate between the</font>
<br><font size=2 face="sans-serif">source color spaces [e.g., Adobe RGB, camera Raw RGB] and particular print related</font>
<br><font size=2 face="sans-serif">output spaces. One question is how constrained should the gamut be? Should it be </font>
<br><font size=2 face="sans-serif">limited to a SWOP-like gamut? Or be like the ISO reference gamut - which is a bit larger. </font>
<br><font size=2 face="sans-serif">Another way of thinking about it is -- Would you want a proofing color space to contain </font>
<br><font size=2 face="sans-serif">the Pantone colors? Or to be limited to a subset of Pantone colors as many real print </font>
<br><font size=2 face="sans-serif">systems are?</font>
<br>
<br><font size=2 face="sans-serif">I think you got the idea I was putting forth. My question is - is that what you and </font><font size=2 face="Courier New">Kai-Uwe</font><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">had in mind?</font>
<br><font size=2 face="sans-serif"><br>
Best regards,<br>
Ann McCarthy<br>
Lexmark CPD<br>
Imaging Systems Engineering<br>
ICC Workflow WG Chair<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Jan-Peter Homann <homann@colormanagement.de></b></font>
<p><font size=1 face="sans-serif">05/02/2006 01:41 PM</font>
<br><font size=1 face="sans-serif">Please respond to homann</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: almccart@lexmark.com, OpenICC Liste <openicc@lists.freedesktop.org></font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: Re: [Openicc] new: Proof colour space</font></table>
<br>
<br>
<br><font size=2 face="Courier New">Hello Ann, and all,<br>
Nice to hear, that leading ICC members are reading and posting to the <br>
openICC list :-)<br>
<br>
I think, your answer is two steps ahead, of the mail of Kai-Uwe.<br>
As I understand him, he want the possibility of a free choosable <br>
proofing colorspace independent from the RGB- or CMYK-workingspace in <br>
ICC aware open source applications.<br>
<br>
As I understand your concept of an "proofing colorspace" as an <br>
intermediate colorspace between widegamut colorspaces like <br>
camera-profiles on RAW data or AdobeRGB and printoutput.<br>
<br>
Finetuning of colors and saturation is done in the "proofing <br>
colorspace", if the work is done, gamutmapping from "proofing <br>
colorspace" to print output colorspace needs and can be done either with <br>
relatice colorinteric and blackpoint-comepnesation or with ICCv4 <br>
perceptual gamutmapping, if the gamut of the "proofing colorspace" is <br>
similar of a better "reference medium gamut" for ICCv4 profiles.<br>
<br>
Do I understand your intentions correct ?<br>
<br>
:-) Jan-Peter<br>
<br>
almccart@lexmark.com wrote:<br>
> <br>
> Hello Jan-Peter and all,<br>
> <br>
> So -- if we were to define a 'proofing colorspace' what would the <br>
> requirements be?<br>
> For example:<br>
> 1. RGB encoding<br>
> 2. Encompassing and similar in shape to the ISO printing gamut defined <br>
> in ISO 12640-3 Annex B<br>
> 3. Not significantly larger than the ISO printing gamut defined in ISO <br>
> 12640-3 Annex B<br>
> 4. Unambiguously defined transformations to/from CIE XYZ<br>
> 5. Primaries placed so that if the file is incorrectly assumed to be <br>
> sRGB, severe hue shifts do not occur.<br>
> 6. Primaries placed so that HVS response to tone and hue adjustments are <br>
> reasonably homogeneous<br>
> throughout the space [i.e., perceptual isometry].<br>
> 7. Adapted white point, color space white point and black point <br>
> chromaticity = D50<br>
> 8. Print-referred image state<br>
> 9. Adapted white point and color space white point luminance: 160 cd/m^2 <br>
> [=ICC PCS]<br>
> 10. Image surround - 20% of adapted white point<br>
> ...?<br>
> <br>
> Does this represent a good initial list of attributes? <br>
> Is there an existing public domain RGB that meets these criteria?<br>
> <br>
> Best regards,<br>
> Ann McCarthy<br>
> Lexmark CPD<br>
> Imaging Systems Engineering<br>
> ICC Workflow WG Chair<br>
> <br>
> <br>
> <br>
> <br>
> *Jan-Peter Homann <homann@colormanagement.de>*<br>
> Sent by: openicc-bounces@lists.freedesktop.org<br>
> <br>
> 05/02/2006 07:41 AM<br>
> Please respond to homann<br>
> <br>
> <br>
> To: Kai-Uwe Behrmann <ku.b@gmx.de><br>
> cc: OpenICC Liste <openicc@lists.freedesktop.org><br>
> Subject: Re: [Openicc] new: Proof colour space<br>
> <br>
> <br>
> <br>
> <br>
> Hello list,<br>
> A proofing colorspace would be very helpful.<br>
> I know several photostudios, which are dealing with agencies, prepress<br>
> bureaus and print shops.<br>
> <br>
> They are working in RGB and deliver RGB and CMYK-Files (ISOcoated) to<br>
> their clients.<br>
> <br>
> Before they are converting to CMYK (ISOcoated) with relative<br>
> colorimetric and blackpoint compensation, they do a proof and optimize<br>
> the RGB-file, if colorclipping of saturated colors are occuring.<br>
> <br>
> The goal is to build an archive of RGB-files, where all RGB-files can be<br>
> converted relative colorimetric with blackpoint compensation to the main<br>
> destination colorspace, without the need to make image by image<br>
> analysis , which rendering intent fits best.</font>
<br><font size=2 face="Courier New">> <br>
> Most uzsers I know prefer to have a special menue for softproofing,<br>
> instead of doing it in the colorsetting file.<br>
> <br>
> Very helpful is also, if the softproof menue is synchronized with the<br>
> menue "convert to profile"<br>
> <br>
> If the softproof is OK, the file can be converted to the destination<br>
> colorspace with one mouseclick.<br>
> <br>
> :-) Jan-Peter<br>
> <br>
> <br>
> Kai-Uwe Behrmann wrote:<br>
> > Hello list,<br>
> ><br>
> > what would you think about a dedicated proof colour space?<br>
> ><br>
> > The current situation in CinePaint is: we have RGB/Cmyk image data <br>
> and can<br>
> > proof them to whatever colour space on screen. If someone wants to<br>
> > simulate an special output device like a film stock or a print media, it<br>
> > seems there is no sense by sticking to the editing colour spaces<br>
> > (RGB/Cmyk). It is not clear if the user wants a RGB or Cmyk colour space<br>
> > to proof against.<br>
> ><br>
> > It could as well mean the proofing options should become a separate<br>
> > advanced configuration group.<br>
> ><br>
> > Whats the opinion on the list about this matter?<br>
> ><br>
> > regards<br>
> > Kai-Uwe Behrmann<br>
> > + development for color management<br>
> > + imaging / panoramas<br>
> > + email: ku.b@gmx.de<br>
> > + http://www.behrmann.name<br>
<br>
<br>
-- <br>
--<br>
<br>
homann colormanagement ------ fon/fax +49 30 611 075 18<br>
Jan-Peter Homann ------------- mobile +49 171 54 70 358<br>
Kastanienallee 71 ------- http://www.colormanagement.de<br>
10435 Berlin --------- mailto:homann@colormanagement.de<br>
</font>
<br>
<br>