Re: [SVGColor] ICC rendering intents and compositing

Let me add a bit to this...

ICC v2 Profiles support only a single rendering intent that is used for
BOTH SIDES of the conversion.  PDF and SVG both only support this single
RI value.

ICC v4 Profiles, however, support DUAL rendering intents where you could
use a separate value for each side.  XPS supports model, and it's been
recommended that PDF 2.0 (ISO 32000-2) be updated to address this as well.
 (though I keep forgetting to do this!!)

Also, both PDF and XPS (but not SVG (IIRC)) support applying the RI on a
per-object (or per-group) basis, since there are some types of objects you
may wish to have rendered differently (eg. An image vs. vector).


The OTHER related thing is support for Black Point Compensation which is
now part of the ICC spec.  We've added support for BPC specification as
part of ISO 32000-2 as well.  I'd recommend that the SVG committee
consider adding it as well.

Leonard


On 7/13/11 6:02 PM, "Chris Lilley" <chris@w3.org> wrote:

>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/R
>LIMS/Volume13/Colour_Constancy_using_von_Kries_Transformations-Colour_Cons
>tancy_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 Thursday, 14 July 2011 13:27:09 UTC