Rv and the pixel aspect ratio

[Missy_of_Science]

Hey all,

so we (the studio I work in) ran into some problems with the pixel aspect ratio of an image.

Say we have two images with a pixel aspect ratio of 2.0 and an alpha channel (here it’s a different one, to make it obvious).

If we over them to compare them directly, the alpha channel would be taken into consideration, resulting in an inaccurate compare.

So lately we switched from over to replace, so that we could compare the rgb channels, without the mask, that was hidden in the alpha. Everything worked like a charm until last week, when we started a project with images that have a par different to 1. Now the images get squished.

But only as long as the wipes are at the edges of the image. Moving them results in a correction of the image that has the changed wipes (left). As a workaround, we could also move the second wipe just slightly and the images would fit perfectly over each other (right):

But doing that every time you want to compare something is somewhat annoying. Also it would have to be just the tiniest bit, because you may want to check the corners. Then also the wipes of the top layer would have to be placed precisely.

Has anyone of you had a similar problem so far and knows what’s causing it?

I figured it would have to do with the wipes. The image seems to be reloaded every time the wipes reach the edge or are moved away from them.

There is a visible change in the images with the difference operation. But here the operation is correct, when the wipes are at their edges, moving them destroys the comparison.

Also, the over operation has a slight quality improvement with the wipes not at the edges. But that is barely noticeable.

Thanks for sharing your knowlegde and thoughts on this (as I think quite intriguing) error.

[alexaz]

To anyone following this thread:

@Missy_of_Science has put in a support ticket with us. This is a known issue with non-square pixel aspect ratio inside of RV and we have an internal ticket to fix it.

Thanks,
Alexa

[Missy_of_Science]

This issue has been known for quite some time now and the Autodesk Support told me about a week ago, that the Development Team is currently not able to fix it and is not interested in fixing it. To them this is simply not important.

So I wrote a package that fixes the symptoms. I upload it with this post for everyone who needs it to use.

I made use of the fact, that the composite stack is correct, when the wipes are moved inwards. So whenever the left edge tries to reach 0 it is forced to 0.0001 (1px in 10K resolution), which is enough for the work around to kick in. So it doesn’t have to be done manually anymore.

stackgroup_fix-1.0.rvpkg (1.1 KB)

[ELeroyCA]

We’ve been having the same issue since forever, we just got the latest 2022 version installed in hopes that it would solve it, but it did not.

We’re getting the issue as long as we’re in Replace mode, even if not wiping.

@alexaz or @Missy_of_Science any chance we can get an ID or reference for the support ticket?

[Missy_of_Science]

Hello Erwan,

the support Ticket is closed as change request. But you could open a new one, so the Development Team sees, that more people have the same problem and boost its importance.
The Case ID is 19645509, and what they so eloquently called Defect ID is SG-20306, which is their internal case.

For us the problem occurs with the wipes off as well and with them on AND moved everything is fine. If that works for you too, feel free to install the stackgroup package I uploaded, it will help with the symptoms, not the cause, but it does its part.

Cheers, Henna