W3C home > Mailing lists > Public > www-svg@w3.org > July 2012

Re: Compositing math in SVG

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 13 Jul 2012 11:42:13 -0700
Message-ID: <CAGN7qDB2jZ0irg+UuAXbSTJz76OKdPdhha8X-VWyeRn58gXLSQ@mail.gmail.com>
To: Calculemus <calculemus1988@gmail.com>
Cc: www-svg@w3.org
On Fri, Jul 13, 2012 at 10:36 AM, Calculemus <calculemus1988@gmail.com>wrote:

> About HDR, the problem is they can take values bigger than 1.
> Let's say I have two HDR images with values in range 0-4.
> Do I first map the range 0-4 to 0-1, do the blend math, and go
> back to 0-4? Do I just do the math on the range 0-4 and
> then clamp?
>

When you blending 2 images, you need to make sure that they are in the same
colorspace (aka the blending colorspace).
If they are, I think you can just apply the blending formula's to the raw
values. (1 in the blending formulas represents the maximum value of the
your colorspace).
If they are not, or the colorspace has no maximum/minimum values, you will
need to convert to a wide gamut colorspace, blend in that and then convert
back.


>
> I am rereading the SVG docs, and I am not sure if the
> general compositing formula implies that I should implement
> all combinations of porter-duff operations and blend modes?
> Or I should just use 'src_over' for blend modes and have
> a separate function for each of the porter-duff operations?
>
> I mean do you need to use any other porter-duff operation
> with blend modes? Does it make sense to do for example
> screen(blend mode) and in(porter-duff)?
>

I agree that some combinations might not make sense.
Compositing and blending are 2 separate operations which is why we pulled
them apart in the new CSS spec.

It will probably make most sense if you implement them seperately in your
code but provide an optimized path for blending + src_over since that will
be 99.9% of all cases.

Rik
Received on Friday, 13 July 2012 18:42:41 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:51 GMT