[Bf-cycles] Color (un)premultiply

[Adriano Oliveira]

In my tests here, OFF is ok only for very dark colors. ON is always ok.

Adriano A. Oliveira



2012/12/12 Brecht Van Lommel <brechtvanlommel at pandora.be>

> Hi,
>
> Right, it looks ok in this case, but it's not only about black
> backgrounds, anything dark will tend to be more correct with the
> option off.
>
> But I just remembered that I can only turn this on once we refactor
> the key/premul system, since otherwise this option would break other
> cases where you're working with key alpha images. Maybe I should try
> to tackle that refactor for 2.66.
>
> Brecht.
>
> On Wed, Dec 12, 2012 at 5:29 PM, Adriano Oliveira
> <adriano.ufrb at gmail.com> wrote:
> > As long as Blender internal compositor works right in linear, I think
> this
> > is just a matter for those who need to compose outside.
> > In real life, composing over black is rare. We are used to compose over
> > other images or color gradients.
> > If the behaviour of the option is correct, as it seams to me, I agree the
> > default value should be ON.
> >
> >
> >
> > Em quarta-feira, 12 de dezembro de 2012, Brecht Van Lommel escreveu:
> >
> >> Right, if you composite it over a black it will be correct result with
> >> the option off, for anything else it's a matter of which result looks
> >> less wrong. In this case having the option on looks better. Maybe
> >> that's true in most cases, then we should change the default.
> >>
> >> Brecht.
> >>
> >> On Wed, Dec 12, 2012 at 4:27 PM, Adriano Oliveira
> >> <adriano.ufrb at gmail.com> wrote:
> >> > See exemple atached:
> >> >
> >> > Render with transparency and saved as TIF 16bits RGBA.
> >> > Composed in Photoshop over a red BG.
> >> >
> >> > Adriano A. Oliveira
> >> >
> >> >
> >> > 2012/12/12 Brecht Van Lommel <brechtvanlommel at pandora.be>
> >> >>
> >> >> Hi,
> >> >>
> >> >> As far as I know, the new color management changes in 2.64 should not
> >> >> introduce any extra fringes compared to before. If that's the case it
> >> >> would be interesting to understand why.
> >> >>
> >> >> This option is definitely a color management option though, and
> >> >> affects compositing as well, I don't think it's correct to place it
> in
> >> >> the Film panel. The exposure option in the film panel will be removed
> >> >> eventually, it's a separation option but it should really be using
> the
> >> >> color management settings instead. Maybe it should be there anyway,
> >> >> but ideally we could find a better way to communicate things rather
> >> >> than duplicating the option, or maybe the default value should be
> >> >> changed.
> >> >>
> >> >> In any case, the unpremultiply option is something that should be
> >> >> avoided when possible, there is no right way to use it, depends a bit
> >> >> on the image what looks best, but the result will be subtly wrong
> >> >> either way. Ideally you should never do color space conversion on an
> >> >> image that has an alpha channel, which means working in linear float
> >> >> color space and only doing the color space conversion at the very end
> >> >> when everything is composited together. Though it's not always
> >> >> possible to set up an entirely correct color pipeline with external
> >> >> tools involved.
> >> >>
> >> >> Brecht.
> >> >>
> >> >> On Wed, Dec 12, 2012 at 3:34 PM, Adriano Oliveira
> >> >> <adriano.ufrb at gmail.com> wrote:
> >> >> > Since 2.64 I've problems with transparency finges when editing
> render
> >> >> > outside Blender.
> >> >> > Last week I discover the "Color unpremultiply" option and every
> thing
> >> >> > is
> >> >> > fine again.
> >> >> >
> >> >> > I supose that many others like me are having hard times dealing
> with
> >> >> > premultiplied fringes due to new Color Management been so far from
> >> >> > render
> >> >> > options.
> >> >> >
> >> >> > My proposal is to merge Color Management in the FILM slider at
> Render
> >> >> > Options.
> >> >> > At least, "Color unpremultiply" option should be near TRANSPARENCY
> >> >> > option,
> >> >> > even if it is repeated in Color Management, like Exposure seams to
> >> >> > be.
> >> >> >
> >> >> > Adriano A. Oliveira
> >> >> >
> >> >> > _______________________________________________
> >> >> > Bf-cycles mailing list
> >> >> > Bf-cycles at blender.org
> >> >> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >> >> >
> >> >> _______________________________________________
> >> >> Bf-cycles mailing list
> >> >> Bf-cycles at blender.org
> >> >> http://lists.blender.org/mailman/listinfo/bf-cycles
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Bf-cycles mailing list
> >> > Bf-cycles at blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >> >
> >> _______________________________________________
> >> Bf-cycles mailing list
> >> Bf-cycles at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> >
> > --
> >
> > Adriano A. Oliveira
> >
> > Livro: http://goo.gl/WtcNX
> > Lattes: http://lattes.cnpq.br/8343393957854863
> > Blog "CG Total": http://cgtotal.net
> > Blog "Anodinidades": http://anodinidades.wordpress.com/
> > Produções audiovisuais: http://vimeo.com/anodinidades/videos
> > Fotografia: http://www.flickr.com/photos/adriano-ol/
> > Facebook: http://www.facebook.com/adriano.ol
> > Twitter: http://twitter.com/anodinidades
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20121212/0681a4e0/attachment.htm