(Bug): [Transform] Pixelization of primitives (ex: Rectangle, Radial, Text)

[pedropaulosuzuki]

Make sure to follow our issue report guidelines

• I'm using the latest version of Natron (not required but recommended)
• I've restarted Natron and the issue persists
• I've run Natron via the command line and the issue persists
• I've followed the contributing guidelines to the best of my understanding
• My issue is not on the issue tracker or in a pull request already (go search for it and dig around a little bit!)
• This bug is reproducible

Natron version

Natron 2.5.0

Operating system

PopOS 22.04 LTS

System specs

CPU: Intel Core i5 4460
GPU: NVIDIA Geforce GTX 750 TI
RAM: 8GB DDR3

Did you install Natron using the official installer?

• Yes, I used the official installer
• No, I installed from a binary archive
• No, I compiled Natron from sources
• No, I installed Natron via another method

Custom installation path

No response

What were you trying to do?

Currently, when inputting primitives (such as Rectangle, Radial and Text) into a Transform node with scale > 1, the inputs get pixelated, as though they were rendered before getting into the Transform. Ideally, such primitives should be position and scaled before rendering takes place. This could help with getting #264 to be better supported in the future, even if not the primary goal of this issue.

What did you expect to happen? What happened instead?

What should happen: transform of position and scale should take precedent on rendering.

What happens: transform of position and scale happen after node rendering resolution, which locks them to their previous resolution and can generate pixelation.

Rectangle (with corner radius):

Radial:

Text:

Step-by-step reproduction instructions

1. Start Natron
2. Add a primitive (for example: rectangle with border radius, radial or text).
3. Add a transform node with scale 5, for example.
4. Connect the primitive to the transform node.
5. Connect the transform node to the view node.

Additional details

Thanks and best regards.

[rodlie]

It's up to each OFX plugin to support concatenate transform.

[pedropaulosuzuki]

It's up to each OFX plugin to support concatenate transform.

Does that mean it should be reported to the individual OpenFx-Misc repos? I'm new to the project.

For example, the Rectangle issue should change this file, right? And the same for Radial and Text, I presume.

[rodlie]

We can move this issue to openfx-misc if needed.

It's been years since I looked at concatenate transform, so I don't know what supports it or not.

For example, the Rectangle issue should change this file, right? And the same for Radial

Correct.

I will not support it in Text (openfx-arena), I remember the issue was cairo (the 2d engine).

I have been working on a new and improved ofx text plugin that could support it, but that plugin is not part of Natron (it's a generic plugin) or done yet.

[devernay]

Not an issue.
This is not an issue with transform concatenation: an OpenFX doesn't know what happens downstream in the graph, and will rasterize the result. Your Text1 plugin above is using a very small font size, and then you zoom on it a lot. But the transform node is downstream, and the text node doesn't know what you're doing with its output.

[pedropaulosuzuki]

Not an issue. Your Text1 plugin above is using a very small font size, and then you zoom on it a lot. But the transform node is downstream, and the text node doesn't know what you're doing with its output.

It is an issue. Of course the examples I made were exaggerated to highlight the issue properly. But imagine you have a primitive and you scale it with a transform to 1.4x. It will look pixelated. That's how I discovered the issue. The only solution would be always overscale the primitives and then never transform scale to be bigger than one. This is clearly an undesired behavior, unless otherwise specified (like with a 'pixelate' option, for example, but not by default).

This is not an issue with transform concatenation: an OpenFX doesn't know what happens downstream in the graph, and will rasterize the result.

That's the point, it should know what's downstream and only rasterize the result after applying all transformations. it should know what's going downstream and evaluate rasterizations only at the end of the pipeline, to avoid getting double or triple pixelation.

This gets even worse if, for example, you keyframe an animation to shrink in a transform node and then use another transform node to make your components bigger down the graph. It will ruin your resolution. Marking this as not an issue would render Natron as a weak option for motion graphics, that use these kinds of transforms a lot, and only render it useful for compositing.

[pedropaulosuzuki]

A simple example that shows why this can become an issue really easily:

Screencast.from.10-06-2024.18.55.39.webm

[rodlie]

Yeah, I misunderstood the question, I though we where talking about concatenation.

Output from the OFX plugin is raster, you can't to anything about that, you can scale up the source nodes and scale them down and them work on them, but it's not a good workflow.

Marking this as not an issue would render Natron as a weak option for motion graphics, that use these kinds of transforms a lot, and only render it useful for compositing.

Natron is not for motion graphics, it's a compositing application.

[devernay]

One feature you could ask for (and @rodlie is the right person to ask) is having the capability to apply a transform inside the ReadSVG node. That way, you could transform the SVG before rasterizing it, rather than after.

[pedropaulosuzuki]

Natron is not for motion graphics, it's a compositing application.

Then we should remove "Open Source Compositing Software For VFX and Motion Graphics" from the website.

[pedropaulosuzuki]

One feature you could ask for (and @rodlie is the right person to ask) is having the capability to apply a transform inside the ReadSVG node. That way, you could transform the SVG before rasterizing it, rather than after.

While that's certainly an improvement (and a big one), we would still have an issue with grouped elements, for example. Maybe apply the merge after the transforms in some way? (Like transform each input of a merge node individually and then combine them later?)

[rodlie]

While that's certainly an improvement (and a big one)

Will add transform support in ReadSVG (NatronGitHub/openfx-arena#25).

Then we should remove "Open Source Compositing Software For VFX and Motion Graphics" from the website.

Maybe, but it can be used for motion graphics, it's just not designed for it (so you have some limitations).

You probably want something more similar to AE etc (https://github.com/friction2d/friction/releases/tag/v0.9.6-rc2).