Crop node doesnt work procedurally #38850

New Issue

levon hudson · 2014-02-26T15:11:28+01:00

levon hudson commented

2014-02-26 15:11:28 +01:00

System Information
OSX 10.8.4

Broken: in both official 2.69 release and trunk build 27/02/14 cf0120b

The crop node gets the input size/position from the original image size, not from the node being piped into it.

if you look at the attached blend file. disabling the scale node, you can see the crop is taking its dimensions from the input image, not from the scaled image.

In the bottom node tree, you can see the crop takes no notice of any transforms applied to the image.

expected behaviour would be the crop is based on 1) the output image dimensions, or ideally 2) the new dimensions of the image after it has been scaled.

crop_bug.blend

**System Information** OSX 10.8.4 Broken: in both official 2.69 release and trunk build 27/02/14 cf0120b The crop node gets the input size/position from the original image size, not from the node being piped into it. if you look at the attached blend file. disabling the scale node, you can see the crop is taking its dimensions from the input image, not from the scaled image. In the bottom node tree, you can see the crop takes no notice of any transforms applied to the image. expected behaviour would be the crop is based on 1) the output image dimensions, or ideally 2) the new dimensions of the image after it has been scaled. [crop_bug.blend](https://archive.blender.org/developer/F79037/crop_bug.blend)

levon hudson commented

2014-02-26 15:11:28 +01:00

Changed status to: 'Open'

levon hudson commented

2014-02-26 15:11:28 +01:00

Added subscriber: @LevonHudson

Lukas Tönne commented

2014-02-26 15:55:07 +01:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2014-02-26 15:55:07 +01:00

"Size" in the compositor is badly defined, but not really a bug: When the crop node uses relative borders this is based on the resolution of the image. This resolution is exactly the same for the input image and the scale/translate node outputs. This is awkward behavior in itself, but it is necessary because the compositor has no other way of defining the relation of different images and node results to each other currently.

The only solution really is to implement proper canvas compositing, which defines a common "canvas space". Nodes can then have pixel resolutions on top of that to do proper sampling.

Until then this must be considered intentional, although undesirable and limiting ...

"Size" in the compositor is badly defined, but not really a bug: When the crop node uses *relative* borders this is based on the __resolution__ of the image. This resolution is exactly the same for the input image and the scale/translate node outputs. This is awkward behavior in itself, but it is necessary because the compositor has no other way of defining the relation of different images and node results to each other currently. The only solution really is to implement proper canvas compositing, which defines a common "canvas space". Nodes can then have pixel resolutions on top of that to do proper sampling. Until then this must be considered intentional, although undesirable and limiting ...

Campbell Barton commented

2014-02-27 03:41:51 +01:00

Changed status from 'Open' to: 'Archived'

Campbell Barton closed this issue

2014-02-27 03:41:51 +01:00

Campbell Barton self-assigned this 2014-02-27 03:41:51 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crop node doesnt work procedurally #38850