Adjustments applied to an image defy warping by CornerPin

This is a new one. I have an image I'm corner-pinning onto a computer screen in a shot. I need to dull it down to match its surroundings.

So I slapped a Brightness/Contrast node on it before running the output into the CornerPin on a PlanarTracker.

Went I went to turn the brightness down, I found that it darkened an entire rectangular area that was not processed (warped into perspective) by the corner pin. Needless to say, this is highly defective.

Two neighboring compositions done exactly the same way don't exhibit this. And I can't fix this one; even if I make a new PlanarTracker.

The simplest shots waste days in this thing.

Turn on the pre-divide/post-multiply option in BrightnessContrast.

Wow. Thanks for that.

The Brightness effect is supposed to be operating on the rectilinear image before it gets to any other node, and the result should be delivered to the PlanarTracker for warping. There are no pixels in much of the area upon which the brightness node is operating by default. Instead, it's darkening underlying image data, to which it has not been applied.

My random guess is that it modifies the border which then gets extrapolated into full domain when the corner pin transform is rasterized. It is not magically darkening the underlay, it is creating values in the insert element that, when composited together with the bg, cause brightness change. For example if you change RGB channel values in area where alpha is zero to be nonzero, regular merge operation will cause brightening or darkening because these RGB values get simply added to incoming BG values with no scaling back of the BG due to zero alpha.

Pre-divide/post-mult will sandwitch the color change between operations that kill the RGB <> alpha discrepancy.

Hey
Just a Captain Obvious note here for useless fun : I found some but there are hardly any situation where this pre-divide/post multiply box shouldn't be ticked in any alpha involved node...
Sometimes not to do it twice in a row for obvious reasons, sometimes because for personal reasons you prefer doing it in a separate node, sometimes just to check things for a second, but usually it should be ticked when given the choice to.

Here, just for the record, if the issue hadn't been related to this detail, it would have been necessary to first get back the right borders selection (with various ways including a Filter node: sobel or more recent Edge detect), and then apply some kind of feathering ...

It shouldn't be ticked when the content of RGB channels should be preserved for whatever reasons in zero and close-to-zero alpha regions. Toggling it on will kill the values. Most obvious example would be when there is anything additive involved like a glow or flare or whatnot.

Yes, this is one of those reasons contained in my "sometimes just to check things for a second", to perfectly eyeball what's different

Thanks for the replies, guys.

I think Nuke's "black outside" checkboxes everywhere are dumb, but Nuke's behavior there only amounts to an incredibly poor default. What we have here, as far as I can tell, is incorrect behavior. I'm trying to justify it in the context of this comment:

"It shouldn't be ticked when the content of RGB channels should be preserved for whatever reasons in zero and close-to-zero alpha regions. Toggling it on will kill the values. Most obvious example would be when there is anything additive involved like a glow or flare or whatnot"

But all of that would be downstream. The fact remains that the image I applied the effect to wasn't transformed when I applied it. I suppose it would be interesting to apply something like a glow and see how far out the DoD goes beyond the bounding box of the image itself.

Black outside is dumb but fulfills its purpose: to allow some explicit user control over extrapolation without actually having a configurable extrapolation mode at all.

To tell whether Fusion behavior is as intended or not we'd have to know:
- extrapolation logic;
- domain of definition expansion logic;

Extrapolation tells how pixel values are "created" when sampling outside image domain of definition area. Downstream operator can make a request for an area that is bigger than the DoD and upstream operator might (not sure) be forced to fill it. Or downstream operator extrapolates the incoming image itself. In either case there is an extrapolation logic for generating the pixel values either by zeroing them, extending edges etc.

DoD expansion fits into the equation in a way where if downstream op makes a request it can be for an area bigger than the DoD of upstream image. In that case the output of upstream might be expanded as per request and new pixels are filled with some data. Now imagine that BrightnessContrast is applied on this expanded region which originally was zeroed. It lifts (or lowers) RGB values while keeping alpha zeroed. CornerPin mode in PlanarTracker gets the expanded image, applies its transformation and rasterizes it into its own output DoD. Obviously there's plenty of areas which need to be filled based on extrapolation rules because the transformed input does not fill it. If extrapolation were to extend edge pixels you get those modified RGB values filling in the whole rectangular DoD area in PlanarTrackers output, which you saw initially.

Whether the above actually fits Fusions inners, don't know, but it might give some clues to how this behavior can come to be. Whether it is incorrect, well, it depends.

If you need to preserve additive elements you have to modify color so that you don't throw the RGB values off randomly. For exposure change do a linear gain for example, it will keep zeroes zeroed.

Hey
Just a Captain Obvious note here for useless fun : I found some but there are hardly any situation where this pre-divide/post multiply box shouldn't be ticked in any alpha involved node...

Besides the glow issue already mentioned, it can sometimes cause some subtle fringing that's a real bear to fix if you don't realize someone's ticked that box.

I forget what the exact circumstances were, but I spent most of a day fighting with a fringe that just wouldn't die because there was a divide/mult downstream of where I was working.

Might have been a precision issue where div and mult don’t arrive at the same value when alpha is close to zero.