Issue with STmaps from Hotsprings

Hi,

Like many others we outsource our (advanced) 3D tracking via Hotsprings. For some reason their default way of working is to not add canvas resolution to their undistorted plate which then results into a redistort cropping of the borders which becomes a problem when CG renders or projections go near/over the borders of the original resolution.
Are we missing some super obvious trick here? Other match-moving companies do seem to assume a 10% overscan on their undistorted plates and a redistort STMapback to the original resolution. This route has always worked well for us, so I’m a bit confused why we have to keep giving this feedback to Hotsprings that we require something different.
I’m kind of hoping there is some trick to this but I’m not seeing without losing some accuracy in the redistort proces.

This happens to me from a variety of vendors. Are they using SythnEyes? Syntheyes for example has, for me, a ridiculous setting where you do in fact output STmaps with the original resolution which for our workflow is as helpful as a screen door on a submarine. So, it’s quite likely that everybody is doing what they think is right but aren’t aware and if they are using Syntheyes then in their Undistort workflow they are choosing the top button and should be choosing the second button down.

After I get the kids to school I’ll post a Syntheyes screen grab for ya, in case that’s it.

I think they almost exclusively use 3DE since they also export a corresponding Nuke script which uses the 3de gizmo. I think we can sort of hack our way out of there using the Nuke script but I just the STmaps to work out of the box.

Ah. Copy. Perhaps, if you ask for the undistored JPEG at the undistorted resolution and the STmap undistort that matches said JPEG resolution that could be a way of forcing the issue?

I think we are literally going to send a nuke script how we think it should work :slight_smile: , what vexes me is that we keep having the same problem and surely we are not the only ones running into this issue.

Didn’t we just have a LogikLive with them? Maybe that feedback needs to get to the right people?

If I remember right, 3DE can compute the bounding box of the overscan, but you have to do that step and copy the values. It’s not automatic.

3 Likes

Perhaps post the stmaps on a link so we can have a look? Don’t need any source clips just those undistort and redistort maps to check it.

1 Like

OK, so we found out the STmaps have data outside the bounding box. This is the issue of them assuming everything will run through Nuke by default. Not ideal but not wrong either.

1 Like

Perhaps you already tried this, but what happens if you try importing as “data window” (as opposed to the default “display window”) under format specific options in the image pulldown for the EXR? Do you get a different resolution?

6 Likes

Yes! Never knew this option was there. It does indeed change the resolution.
You still get the same issue with the redistort since you need to crop to the original resolution for the redistort using rendering outside of the bounding box.

1 Like

wetransfer link.

1 Like

That was my “I was today years old when…” addition. So extremely handy and yet tucked away.

As Britt suggests it’s not wrong and can work. However you are using flame and it would nice to have the service best suited for your workflow.

Please speak to Ben Stallard* and patiently ask for the st maps to be the same canvas size as the undistored plate. Nothing outside the bounding box. We at Rascal have been through the same pain. I’m pretty sure we wrote a spec sheet for this. You could try asking them to use the same spec sheet as us at Rascal.

*he’s a nice guy and will help.

You might have success using @cnoellert’s trick to using STMaps with negative values. It’s a very clever solve.

1 Like