[Bf-vfx] Tomato camera sensor changes

[Ejner Fergo]

Hola all,

>> 2011/10/19 Brecht Van Lommel <brechtvanlommel at pandora.be>
>>
>> Hi all,
>>
>> I think it would be good to get the full sensor size patch in 2.61 and
>> I can review it,

I agree and would love to see this happening! (no surprise)

>> I don't object to a sensor height property that doesn't affect blender
>> internal. The resolution gate image linked here explained to me why it
>> can be useful, and  especially if it can be visualized in the
>> viewport. But I don't understand how it's correct to use the sensor
>> width as sensor height in some cases, I'm trying to understand if it's
>> a particular case of resolution gate fitting but I don't see it. How
>> would you export the 'portrait' case to get matching renders in other
>> applications?

Even if it doesn't affect rendering currently having
sensor_height/vfov is still useful, right now only for import/export,
but hopefully in the future it will prepare for independence between
render output and camera (resolutiongate vs. filmgate).

That the sensor_width becomes sensor_height in portrait, is as
Francois writes, because the camera is rotated. But not according to
the settings. I don't know how Blender Internal works and how the
resolution ties in to all this - I guess the sensor has to conform to
the output resolution (and not the other way around) so the sensor
width becomes the longest output dimension (the height for portrait).
So a hypothetical export of this portrait case would most likely
result in a wrong focal length in other apps, because the
sensor_width/hfov would be used literally as the horizontal value,
assuming the app even accepts hfov for import.

>>On Wed, Oct 19, 2011 at 10:27 PM, François T. <francoistarlier at gmail.com> wrote:
>>
>> concerning the presets. Everything is saved (filmgate, focal, distortion)
>> which at some point does make sense, since you would probably more likely
>> create lens profile rather than camera profile.
>> But right now, the design of the preset is only suited for prime lens. Maybe
>> it would be better to make it work for zoom lens as well, meaning one
>> profile contain several focal and for each focal there is a distortion
>> value.
>> To create a zoom profile you would take videos at different step of focal
>> (24mm, 28mm, 30mm, ... 70mm). then compute distortion for each step. This
>> will give you a graph of the distortion (interpolation) so you would have
>> some kind of approximation of distortion of in-between. (which you might
>> even refine, when you computed the lens correctly and want to fine tune the
>> distortion a little bit.
>> otherwise it could be pending until tomato supports zoom lens, but I figure
>> it might be better to do it in the first place. (not really the topic, but I
>> lost the mail with the code review)
>>
>> F.

I just saw that the tracking camera presets have more data. Personally
I would prefer that there was only one shared camera preset, and the
extra data (except lens info) seems negligible to have in a preset
IMHO, or at least it could still be shared. Having lens data as
presets themselves makes much more sense. BTW, if there is so much
trouble over a 2-dimensional setting, what will the reaction to your
proposed lens distortion workflow be? ;) And does/can
http://lensfun.berlios.de fit into this?

Again I'm happy that Brecht supports the full sensor patch and hope to
see it in 2.61. I will dust off the camera import/export work I've
been doing just in case, and will gladly update all presets with their
respective height values :)

Best regards,
Ejner