Hey, I've got one question regarding camera crop in Solaris. What frequently happens on our projects, is that we get matchmoved camera footage, that's lets say 4:3 image aspect. But delivery is in 16:9. Cropping the render area to 16:9 in Houdini may obviously save a lot of render time.

This used to be pretty easy with top/bottom crop parameters on camera object, but on USD camera I only have found something called "Screen Window" parm, which I thought is the thing, but it's not doing what we want (which is not changing the image aspect, or what you see, just introducing black bars).

At first I though I'm gonna go around it by occluding top/btm parts of the image by a grid, based on camera view. Not extremely elegant but it'd do the job. Unfortunately, that doesn't seem to be possible as importing LOP camera into SOPs only gives you a point in space, which is not enough to calculate the viewing direction and frustum.

Am I missing something? Is there a plan to add a feature that would allow for rendering black bars? Or doe anybody have a suggestion on how to go about that? This sounds like something that should be totaly doable

thanks for any hints.

The camera lop has an aspect ratio parameter (under the view tab) and it might be enough to simply change from 4:3 to 16:9. It should do what you want (crop top/bottom) because the default behavior is to retain the horizontal aperture and automatically adjust the vertical aperture.

well yes, that is exactly what we don't want. We want to keep the 4:3 image aspect, but the image portions that are outside the crop should be just black bars (this is how crop parms work in obj context).

edit:
I mean, changing the aperture would work to save the render time, but thing is sometimes this crop happens in the middle of the production, with some comp work done already. When we give compers 1920x1080 frame, instead of 1920x1440 they worked with before, it may potentially break things for them (they can easily reformat the image, but still it's introducing space for an error). Black bars on the other hand make it obvious to see what's happening, and it is also the safest approach i think.

On the USD RenderSetting prim there is a dataWindowNDC attribute which defaults to (0, 0, 1, 1). To float a 16x9 render area inside a 4x3 image, you can set this to (0, 0.125, 1, 0.875) (assuming I got my math right).

robp_sidefx
On the USD RenderSetting prim there is a dataWindowNDC attribute which defaults to (0, 0, 1, 1). To float a 16x9 render area inside a 4x3 image, you can set this to (0, 0.125, 1, 0.875) (assuming I got my math right).

hm, thanks for that. This is what i needed.

I was playing around with Data Window NDC yesterday, but couldn't get this result no matter what i was doing (every time i was getting either stretched/squashed image, or wrong aperture).

Today i don't seem to be able to replicate this stretchy/squashy behavior. But I guess the Aspect Ratio parm on Camera LOP was not matching the resolution parm on rendersettings LOP, and then things went weird. Or something like that - I still find it a bit cryptic to be honest. Shouldn't aspect ratio and resolution be just one parameter? Or is there any particular situation when it is helpful to have it decoupled like this?

Anyways, thanks for your help!

davpe
every time i was getting either stretched/squashed image, or wrong aperture

In some quick local testing I see the viewport sometimes presents a stretched/squashed image (rather than floating the cropped area), but rendering to disk/mplay seems to work consistently. If you observe any issues, please do let us know.

I'll leave it to others to comment on workflows where the ratio of the apertures and the ratio of the resolutions would be different. I expect anamorphic work to be mentioned.

Alright, that's a good point. I haven't even tried rendering to disk, as I was stuck and confused by it's weird behaviour. I would say it was giving me unexpected results in mplay as well, but I cannot be sure now. I was also making tests in both H19.0 (production verion) and H20.0, where some things have changed a bit, which probably did not help me to figure it out.

As for decoupled aspect ratio and resolution parms, I guess it is just about getting used to it, and I can see it is already expression linked in H20.

davpe
Hey, I've got one question regarding camera crop in Solaris. What frequently happens on our projects, is that we get matchmoved camera footage, that's lets say 4:3 image aspect. But delivery is in 16:9. Cropping the render area to 16:9 in Houdini may obviously save a lot of render time.

This used to be pretty easy with top/bottom crop parameters on camera object, but on USD camera I only have found something called "Screen Window" parm, which I thought is the thing, but it's not doing what we want (which is not changing the image aspect, or what you see, just introducing black bars).

At first I though I'm gonna go around it by occluding top/btm parts of the image by a grid, based on camera view. Not extremely elegant but it'd do the job. Unfortunately, that doesn't seem to be possible as importing LOP camera into SOPs only gives you a point in space, which is not enough to calculate the viewing direction and frustum.

Am I missing something? Is there a plan to add a feature that would allow for rendering black bars? Or doe anybody have a suggestion on how to go about that? This sounds like something that should be totaly doable

thanks for any hints.

Workflow-wise, the layout department might want to publish new cameras with a different back plate (at working resolution) for the team to use rather than hacking something based on the integration camera on a user by user basis.

jsmack
Workflow-wise, the layout department might want to publish new cameras with a different back plate (at working resolution) for the team to use rather than hacking something based on the integration camera on a user by user basis.

depends on type of projects i guess. what you say may be fine for long form productions where time budget is counted in months. In commercials and music videos, turnarounds can be obviously very short. Sometimes you get client notes literally hours before the final delivery, and it is vital to be able to cut corners anywhere possible. Pulling new set of plates and cameras, and updating everything "by the book" is simply out of the question when you need to deliver updated renders in 40 mins. Hacking your way through is the only way how to make it. And that's why we love Houdini - you can hack the sh*t out of it