search

MrKepzie / Natron

Open-source compositing software. Node-graph based. Similar in functionalities to Adobe After Effects and Nuke by The Foundry.
www.natron.fr
GNU General Public License v2.0
1.49k stars 164 forks source link

PIKColor gives black rims when "patch black" is used #1502

Closed CameraRick closed 7 years ago

CameraRick commented 7 years ago

Problem

As soon as you raise the "patch black" slider, you get some sort of black "rim" around the area you try to patch. See here: http://i.imgur.com/3Pkwhy6.jpg

Expected behavior: there should be no black.

Actual behavior: there is black :/

Steps to Reproduce

  1. Create a PIKColor node and connect a green-/bluescreen plate
  2. Set it up properly
  3. Patch black
  4. see black rims

The issue roots from the ErodeBlur node(s) and its blur-setting. As I understand it, this is set up this way to mimic Nukes behaviour of the FilterErode-node set to Gaussian filter, which I guess was the direct 'inspiration' for the entire node-setup. The difference why Nukes system works without the black rims is because the white areas get "bigger" from the operation, while in Natron they get smaller. Meaning that detail is simply blurred away and the black comes thru. I looked at the issue a bit and found that it might be easily solvable if the ErodeSmooth node is used instead; I also build a version and attached it: PIKColor_demo.py.zip Now I think this can be improved with better settings, but for now it does a fairly good job not getting the black artifacts: http://i.imgur.com/hoxEu0K.jpg

I think PIKColor could be improved even more with the EdgeExtend node so the initial blur triggered by "size" doesn't suck up as much detail, that way PIKColor could serve more other operations than only PIK :)

Versions

devernay commented 7 years ago

wrong sign in the erodeblur parameter maybe?

CameraRick commented 7 years ago

I don't know, I didn't set it up :o What do you mean by sign? There's not much to set up in there; negative values for Blur won't work screen shot 2016-11-17 at 16 42 15

devernay commented 7 years ago

ok there are two things:

CameraRick commented 7 years ago

I actually think that PIKColor is a 1:1 translation of IBKColor, from the exact layout of the nodes down to the names for expressions and Nodes... :/ The patch-black merge in the end is something I found silly too, I wouldn't build it like that, in my demo-version I didn't really alter it to hand out results which are more like they were before. Personally I'd use the output of the Clamp-node, adjusting it to only work in RGB, premult that and get the result of the patch black "under" it (of course you could over it the oter way around, I just like to keep the B pipe top to bottom). The patck-black doesn't need to be premultiplied in any way. A little blur which only affects alpha before the premult of the main-pipe, which is linked to the patch black somehow, could give the softer edge that ErodeFilter introduces.

ErodeBlur doesn't work that great in this tool, I feel so too. Actually I quite like it for despotting, but I never use the blur-part, haha :)

devernay commented 7 years ago

In the output of the Clamp (or rather the ChannelCopy1 right after it to get RGB) there are strong edges, that may have a wrong color. I think that's the reason why the merge is over it, not under. The output of patch black has softer edges. I just finished the nuke gizmo and the pyplug will come later (sorry for Natron, but making a PyPlug in Natron is still a PITA).

CameraRick commented 7 years ago

But why the ChannelCopy to get the RGB? The RGB doesn't need to be clamped, exluded from the Clamp-operation it's everything you need :)

These wrong colored edges come from leftovers in the screen. You should lower the darks for the screen colour or use the erode to get at least as possible to begin with. However in reality, this is not the biggest issue as these are usually sitting in the opaque area of the resulting matte rather than the edge-area, at least in case of a PIK-Key this is not so probelmativ because a core-key is needed either way.

The over makes sense to get rid of the last leftovers, something the PIKColor can't do at the moment. Using the ErodeSmooth (as in my sample) works better, but can be too aggressive towards different shades of green at times, you can see that in my example where the guy slightly right to the middle has a darker shade on the left and brighter on the right, this isn't adjusting in the patch (which is overall the dark shade).

I don'tr know if this helps you, but I find building Macros in Natron pretty neat by now. It sometimes crashes on me when closing the add-user-buttons-menu on OSX but that's fine. Except for some quirks like not working Expressions, I sometimes find it even better than in Nuke tbh, because of the options I have (this begins with the mask-inputs and goes over limits for sliders etc). I'd just love to be able to Copy+Paste the group into a text editor instead of exporting it everytime :)

devernay commented 7 years ago

because the use of Clamp is a hack to extract everything which is not zero. look at it: min=max=0, maxclampto=1

I'd just love to be able to Copy+Paste the group into a text editor instead of exporting it everytime :)

will be possible or easy to do in 2.2. The project format was changed from XML to YAML, and the PyPlugs will be YAML too - much easier for humans to read! You can have a peek at https://github.com/MrKepzie/Natron/blob/master/Gui/Resources/PyPlugs/PIKColor.nps

CameraRick commented 7 years ago

Well the great thing in node-based that everything that does what you need is not really a hack :) I'd actually use a gamma set to 0, but that seems broken in Natron (for grade+viewer at least)

Great stuff you have there in 2.2!

devernay commented 7 years ago

Gamma=0 works for me, but does the opposite (everything below 1 is set to 0), and it's probably much slower. Just noticed that it works in Gamma but not in Grade, will fix that.

devernay commented 7 years ago

also note that Gamma=0 produces infinity values for any input > 1. You should always prefer Clamp for this task (even on Nuke!). I modified Grade to reproduce the behavior

CameraRick commented 7 years ago

I actually use gamma only in the viewer to get this result (checking mattes), in a grade I usually rely on black+white point adjustment. I usually have no use for such sharp edges :)

CameraRick commented 7 years ago

Does it work in your viewer too? I get all black when I set it to 0, even for values at 1

devernay commented 7 years ago

will check

devernay commented 7 years ago

should be fixed in the latest snapshot

CameraRick commented 7 years ago

I looked at every thing (gamma in viewer, grade, and of course black rims in PIK)

Viewer and PIK work great now :) however in the grade (and actually also the gamma node) it works strange: http://i.imgur.com/AUCRRsD.png

It's a default radial set to .5 softness The values are clearly not at 1 anymore, but this frizzy edge happens; I noticed that everything looks fine as long as the alpha is also checked, this result only happens when only RGB is checked. Is this expected?