Problem Rendering Mattes with MR

[luceric]

As i said.. you need to unpremultiply the image if you're going to be reapply the matte for it separately. Otherwise the transparency will be applied twice because it's already been applied once when you rendered the image. You could render the image unpremultiplied, if this clarifies things (it's a render option in xsi)

[Lord Futzi Voldemort]

As i said.. you need to unpremultiply the image if you're going to be reapply the matte for it separately. Otherwise the transparency will be applied twice because it's already been applied once when you rendered the image. You could render the image unpremultiplied, if this clarifies things (it's a render option in xsi)

Are you actually reading my posts?
There are NO transparencies. Especially in my last example. No alpha. NO transparency. NOTHING gets premultiplied with ANYTHING.

Please check all my images and read my posts carefully before you post the same statement again. You´re obviously not understanding what I´m talking about.

Achim

[Lord Futzi Voldemort]

I did another setup, to avoid further confusion:

One plane. Two polygons. Two clusters, one polygon each, on the same object.
First render: left cluster white constant, right cluster black constant, no alpha saved with the image.
Second render: left cluster black constant, right cluster white constant. Same scene, same object, same camera, same rendersettings (1,3 0.035 Standard sampling).
Just for comparison: render 2 added over render 1 in photoshop. The dark line in the middle is clearly visible.
I don´t know how to make it any more clearer. Anyone can try that at home.

Achim

[origin]

hey lord your attitude sucks first of all Luc is right.

second of all
your antialiased pixels were multipled by color of background (YES I KNOW YOU DONT HAVE ALPHA IN YOUR IMAGE IT DOESNT MATTER)
this produces all kind of problems when compositing

1 multiply background (if its solid color its simple const image in nuke, if it's not, you need to render separate backgroud) by inverted mask of your sphere
2 merge minus sphere image (with copy-alpha channel from your mask) from result of point 1

result is isolated sphere on black background with proper premultplied alpha. now you can do color corrections, switch background etc.

this probably doesnt make sense, so I recommend this tutorial http://www.thegnomonworkshop.com/store/product/431/

don't learn from my nuke tree, i dont know nuke but the procedure is the same in all comp software

[Lord Futzi Voldemort]

Sorry for showing an "attitude". I just still feel missunderstood.

I don´t understand with what background color my antialiased pixels are multiplied, when my "background" isn´t visible to the renderer.
That´s the whole point.
And I wouldn´t post this, if the solutions luc suggested would solve the problem.
In my last example the antialiased pixel should add up to one, shouldn´t they?

Achim

[rray]

just an idea didn't follow the thread throughly.... it could have to do with gamma correction

* I remember I read somewhere it's good to use linear gamma (1.0) during compositing - am not an expert on this subject might have to do with this...

[Lord Futzi Voldemort]

just an idea didn't follow the thread throughly.... it could have to do with gamma correction

* I remember I read somewhere it's good to use linear gamma (1.0) during compositing - am not an expert on this subject might have to do with this...

Tried that to.

Origin: did you render your "mattesphere" against background (empty space) or against black geometry?

Achim

[origin]

against grid with black constant (0,0,0,1) but it doesn't matter, it could be (0,0,0,0) bg, result will be the same.

[Lord Futzi Voldemort]

against grid with black constant (0,0,0,1) but it doesn't matter, it could be (0,0,0,0) bg, result will be the same.

Ok. The thing is, your setup looks right, but the problem still exists. You just don´t see it, because your cutout sphere is not composited over the original. What you did, ist exactly what, as I understand it, the merge node does internally.
If you compare the result with the original image you´ll find, that the sphere in the result is exactly the amount smaller that corresponds with the mattesphere which, as I pointed out ist too small. You don´t see the fringe, because you just cut it away. That´s exactly, what my first image shows.



here´s a look at the matte you´re creating. No operation in nuke changes the fact, that the white mattearea is too small.



If I really can use alphachannels, everything luc said is true of course, and I have no problems at all. So the workaround would be to creat a suitable alpha channel instead of black and white mattes, using the matteshader, whatever problems may occur with that then....


Achim

[origin]

There is no problem with my setup.
This is no workaround but the only way to deal with that stuff (it might be easier in nuke, some dedicated node, dunno, don't know nuke).
You can't composite it over original image beacuse you will end with doubled antialiased pixel colors, you composite it over image*(inverted alpha) (point 1. in my previous post) and some changes in merge node since alpha is not solid.
As result alpha of sphere is *exactly* the same as original, input & output image is *exactly the same*

This is no magic, it's simple MATH.

[Lord Futzi Voldemort]

There is no problem with my setup.
This is no workaround but the only way to deal with that stuff (it might be easier in nuke, some dedicated node, dunno, don't know nuke).
You can't composite it over original image beacuse you will end with doubled antialiased pixel colors, you composite it over image*(inverted alpha) (point 1. in my previous post) and some changes in merge node since alpha is not solid.
As result alpha of sphere is *exactly* the same as original, input & output image is *exactly the same*

This is no magic, it's simple MATH.

No there is no problem with your setup. But the matte sphere is not the same as the one in the colorpass, at least with my images, so there is a problem with the matte input. Why that is, I´m trying to find out. I mean I can see that clearly in the screenshots.
I know there is no magic involved. I´m working in the bussiness for a while now.

Achim




Achim

[origin]

well i don't know why its 1 pixel smaller in your setup
For few years I use EXR & lwf & square pixel to ensure there are no problems in compositing (if you're using 8bit images, dividing/subtracting nodes can give bad results, don't know if nuke internally converts everything to float)

[Lord Futzi Voldemort]

Ok, I think going for exr makes sense anyway, but for me the question remains: why appears an object in different sizes when rendered with different shaders. And thats completely apart from all compositing issues.

Thanks for all your help though, and sorry for being stubborn and impatient, but this problem really blocks me quite a bit.


Achim

[Maximus]

just a quick guess i got from a friend, since i dont have nuke and he told me to try this, he said there should be a preference in the import node in nuke called "Raw Data" try to use that and see if it solves the issue.

I'm still a bit confused on the whole thing, tryin with fxtree

[rray]

Forgive my noob ignorance but doesn't it come down to this
Say I want to mask out the red in this gradient:


when using this b/w "mask" gradient:


in photoshop I get this (mutiply 100%)


Red "seam" in there. Seems obvious why this happens. Also premultiplcation won't work here because we're not dealing with transparencies.

I guess my point is to ask: Isn't this (more or less apparent) a natural occurence when compositing this way? (antialias=gradient after all)

[Lord Futzi Voldemort]

Yes to some degree this is natural, as origin pointed out.
What I need to know in the first place ist where the difference in the covered area comes from, if you compare the alpha as such with something that should look the same, rendered with "colors", as it were.


That results in two gradients that differ in space, even if their "curves" or interpolation from 0 to 1 are the same. So doing math with one another will only work properly in areas where the coverages overlap, correct me if I´m wrong. Also gamma changes would not change the areas that have values greater that 0, but only, well, values. Also, since alpha and color come from the same source, color depth shouldn´t make a difference ( only in precision), again, correct me if I´m wrong. I´ll try that anyway, but not today.

Achim