I have found that the builds after June 4th address the texture to scale distortion bug.

(for the records the original claim that clamping is the issue could be solved with P494, but RNA is already clamping the values before we get to the compositor, so this patch is uneeded)

This is not related to the directional blur node. Here is an even simpler file using another node:

Confirmed. Note to other testers on how to test it:

• Load file, enable auto-run scripts
• Switch viewport to rendered
• The viewport has nothing rendered.

The title is based on initial observations.
It is definitely a bug so I will leave it to developers to figure it out.

I see that too, and all I have to do is go Converter > Math and it renders corrupted. Even before I hook it up.
Title maybe should be changed to "....cause corrupted backdrop image"

Decided to play with the texture node before plugging it into Scale offset

In T51705#438514, @Aaron Carlisle (Blendify) wrote:

Please try with a build from builder.blender.org/download

Sorry about that!
Note taken.

There is no need of blend file.

Please try with a build from builder.blender.org/download

I have same crash with Win7 64 bit and ATI HD4670

In T51705#438461, @Joel Godin (FloridaJo) wrote:

Do you mean like this?

Yes, that's the setup that crashes Blender.
It was mentioned from another user I just replicated it on my machine.

Thanks for the report but it would be helpful if you add a blend-file to the report that demonstrates the issue at hand.

Do you mean like this?

Brought behavior back to how it was before. But i find this all weak, and some cleaner design (which follows artists' expectations instead of dictating them how to use something) is really needed in compositor.

@Aaron Carlisle (Blendify), so "squished" part i think we can investigate (as in "resolution" if you wish).

@Sergey Sharybin (sergey) but why did it work in 2.77?

Scaling down can not work within the current compositor design. Fixing this issue would mean changing the design completely, which is out of the scope of the bug tracker.

This is a known limitation. Output node doesn't know of the nature of the data and assumes this is image pixels.

Anti-aliasing happens from the outside side of the spline, which is actually happened to be an inner side of your "buggy" spline. Just switch direction of the spline and anti-alias will work fine.

This was a poorly implemented feature which was not thread-safe and was causing lots of crashes. It was disabled in the code, but interface part remained. Thus happened 3 years ago, so think it's safe to let this feature to disappear from the interface.

Unfortunately, this is a limitation of the current compositor design, which has half-finished canvas awareness. The following internal issues are happening:

I see what you want to achieve now. Afraid you'll need to follow some workaround like @ronan ducluzeau (zeauro) suggests with the current BI design.

You can add a boolean modifier to your UpperCube.

If you would not specify mask at all you'll have the result you're looking for here.

I tried this, but it gives me wrong result. Upper cube's outline doesn't follow lower cube contour.

Thanks for the report, but the code is working as it was designed to (and here i don't mean it is not confusing for artists). The Edge enhance pass is using Z-pass calculated for objects from current render layer objects and objects which are set by Z-pass mask layers. So adding Z-pass mask does not mean you exclude that unselected layers from edge enhancement.

Final render and preview are having decoupled render border settings. This way you can keep tweaking some specific area in the compo and hit F12 to have a better idea of what's happening on the frame. There is currently no way to automatically inform compositor that some render result was cropped and that it should not calculate anything outside of that region.

hi,
so maybe : diff
(same issue in Directional Blur)