Anyone successfully implemented i-data from RED in their workflows?

[Gunleik Groven]

Question sorta says it.

g

 

[Gunleik Groven]

I'll fill in a bit...

As far as I can understand, i-data can be accessed through the ethernet port, but for post use it needs to be TC-synced (and probably gen-locked)

Second question is:
How precise would i-data be, compared to genlocked data from a FIZ + a lens distortion map?

I imagine that i-data from f. ex. REDs zooms is not precisely calibrated on individual lens base, but are more generic. I might of course be wrong.

Anyone know how this is handled in the Cook lenses or in the ARRI LDS system?

G

 

[Mike Harrington]

Talked to the syntheyes developer about this and he was saying it is much better to let the software handle the focal estimation.

Wasn't even interested in it.

Sorry if that doesn't help....just 3d tracking that is the only situation in my work where it would seem useful

As far as distortion...does i-data support that?

 

[Björn Benckert]

Talked to the syntheyes developer about this and he was saying it is much better to let the software handle the focal estimation.

Wasn't even interested in it.

Sorry if that doesn't help....just 3d tracking that is the only situation in my work where it would seem useful

As far as distortion...does i-data support that?

If you can give a 3d tracker the zoom variable that helps a whole lot... Even if it's an unknown zoom curve, just numbers going up and down and not the exact focal length values, it would still be a huge help. Do not understand why SE developers would say such a thing. And yes SE works tons better if you give it the right sensor size and focal length, it's pretty much a must if you want a track that is accurate in scale etc to the real camera move.

Lens correction can be scripted to focus and zoom quite easily. If you shoot grids in a few instances.

But gunliek, I think you will find that the best way to get to that data is to bite the bullet and buy the RED lens controller. I was looking into the same thing for a feature where post demanded lens info and according to my findings that was the best option.

 

[Mike Harrington]

I think problem was what do you do when the i-data doesn't agree with the focal length calculated by SE. If the lens distortion is calculated properly, and the sensor size is properly input (changes when cropped to 4k etc) then mathematically the result SE comes up with is the correct result. (in theory)
On a properly calibrated lens, the data may be very relevant...on others not so much.

But because the 2 are so locked together (sensor size and focal length) software can 'fudge' the numbers to approximate a solve, whereas forcing it to use a given focal length doesn't allow it any wiggle room while calculating a solve. And it is all an approximation anyway there is never a physically accurate solve....especially with rolling shutter and other artifacts to take into account.

I think it is still a good idea (hence why I talked to him about it)....the data could still be useful as a guideline for the solve, maybe not treated as an absolute, especially in zooms.

 

[Mike Harrington]

And yes SE works tons better if you give it the right sensor size and focal length, it's pretty much a must if you want a track that is accurate in scale etc to the real camera move.

Sensor size will not affect scale at all, but focal length. The 2 are totally interlocked, so an improper sensor size will give you an improper focal length. The scene scale is arbitrary.

I calculate the size for every shot based on pixels, 5.2 microns for the non dragon sensors x image width