[SVGColor] ICC rendering intents and compositing

Hello SVG,

IRC transcript of a conversation between Nick Hofstead, Nick Van den Bleeken and myself regarding rendering intent and compositing.

<nick> ChrisL: Could I ask you a question related to ICC and SVG (I'm Nick Van den Bleeken from the XForms WG)
*** nhofsted (nhofsted@188.118.12.165) has joined #svg
 [ChrisL] hi nick,sure
<nick> tnx, a colleage of mine nhofsted sent a message to the list http://lists.w3.org/Archives/Public/www-svg/2011Jul/0028.html
 [ChrisL] yes, i saw that. the svg wg discussed it on the last conference call
 [ChrisL] i have the action to respond to it
<nick> ok, nice
<nick> was wondering if it was under deiscussion
 [ChrisL] i could have responded in an individual capacity but wanted a resolution of the whole WG on it
 [ChrisL] yes it was
<nick> thanks in advance for the response
 [ChrisL] sorry if it seemed like it fell into a hole
<nhofsted> hi
<nick> np
<nhofsted> no problem ... I hope I made myself clear
 [ChrisL] very clear, yes
 [ChrisL] and the answer is pretty much 'yes tou are right for svg 1.1 and for svg colour you are part right'
<nhofsted> should you need more input, use cases or background, feel free to contact me
<nhofsted> looking forward to the full answer now :)
 [ChrisL] i may well do that. in particular i am not sure of the correct processing is the processor asks for a given rendering intent and the profile in question does not have tables to cover that rendering intent
 [ChrisL] what is the fallback strrategy
 [ChrisL] i also hear that rendering intent may be substantially changed in ICC v.2
<nhofsted> I guess the fallback is defined by the ICC, but that's a corner case. The question what should happen in case everything goes smooth is interesting enough to start with ...
 [ChrisL] yes, agreed
 [ChrisL] is it true to say that the rendering intend going *to* the pcs and going *from* the pcs to the output should always be the same?
 [ChrisL] or would you sometimes do, say, perceptual to PCS then relative colorimetric to output?
<nhofsted> err ... no, you only use the rendering intent going 'from' the pcs
 [ChrisL] oops my bad
 [ChrisL] ah because no colour from the input profile will ever be out of gamut in the pcs
<nhofsted> uhu
<nhofsted> (but it's hairier than that)
 [ChrisL] yes?
<nhofsted> it's not as if the input space doesn't play a role
<nhofsted> you're trying to fit one gamut inside another (in case of relative colorimetric), so the input space does play a role
 [ChrisL] is it always the entire gamut?
<nhofsted> I assume so, otherwise colors would change depending on what other colors you're using
<nhofsted> (and that doesn't mesh with the api of lcms for example)
 [ChrisL] example: i have a colour space that is large, say  ProPhotoRGB
 [ChrisL] and i have a photo thatis mainly mid greys and light flesh tones, no saturated colours at all
 [ChrisL] so i am exercising a small area of the total gamut. and all the coours fir into, say, sRGB or some print profile
<nhofsted> relative colorimetric will have an effect on all colors, also the ones that could've been mapped exactly
 [ChrisL] do i have to compress everything down so that the unused colours *would have* fitted, despite all the colours I used already fitting?
 [ChrisL] ok
<nhofsted> I believe so ... I'll try and dig up a ref
 [ChrisL] and perceptual tries to keep the exact ones the same
 [ChrisL] the definition of perceptual seems a bit handwavy and 'magic can happen in here'
<nhofsted> I'm always mixing the intents up, so double-check, but yeah, there is an intent that does that :)
 [ChrisL] heh
 [ChrisL] ok well I need to get to my next call. but thanks to you both for dropping into IRC and for the helpful comments. I will send the response on behalf of the WG soon
<nhofsted> ok, I'll probably follow up on the mailing list then :)
<nhofsted> Thanks for discussing it and apologies if I appeared a bit anxious ...
<nhofsted> http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm
 [ChrisL] no, i should have sent a 'we are discussing it' follow up, my bad
<nhofsted> np, the link I just posted has a good explanation and explains why relative colorimetric changes all colors ...
<nhofsted> sorry .. perceptual
<nhofsted> (see: I always mix them up :) )
[ChrisL] for relative colorimetric with a white point shift, is that an adaptation matrix like Von Kries?
<nhofsted> that goes over my head :)
 [ChrisL] http://www.massey.ac.nz/massey/fms/Colleges/College%20of%20Sciences/IIMS/RLIMS/Volume13/Colour_Constancy_using_von_Kries_Transformations-Colour_Constancy_goes_to_the_Lab.pdf
<nhofsted> I'm interested because of my work in another working group standardizing a printer language, but from the standpoint of someone generating print-streams .. I only have to specify everything correctly, the actual processing is done by other people :) So I kindof understand it from a tool or requirements viewpoint, but the technical details are beyond me ...
 [ChrisL] http://brucelindbloom.com/index.html?ChromAdaptCalcHelp.html
 [ChrisL] ah okay
*** vhardy (vhardy@192.150.10.201) has joined #svg
 [ChrisL] well i need to get to my call which is starting. will respond on-list likely the start of next week (tomorrow is a holiday here in France)
<nhofsted> btw: should the working group be interested in being in contact with printer - and thus mainly cmyk - folk for requirements gathering or such, I could set something up
<nhofsted> ok cya
[ChrisL] that would be great in fact, yes





-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Wednesday, 13 July 2011 16:03:27 UTC