[Bf-vfx] Tomato camera sensor changes
Sergey I. Sharybin
g.ulairi at gmail.com
Thu Aug 18 19:53:47 CEST 2011
Main problem is in "default" use-case. In Blender we've got defined
resolution and pixel aspect. So as soon as we've defined horizontal size
of sensor, it's vertical size is defined automaticly.
What we've discussed with Francois was that it could be useful to "lock"
one of parameters and specify all the rest parameters which defines
camera settings. It shouldn't be so confusing as it was before, but it
still needs deeper thoughts which i haven't got time to dig deep into.
Having access to vertical FOV isn't so big issue -- it easily could be
read-only property which will be used by exporters.
The most confusing this of that horizontal/vertical fov was then
vertical fov made no effect on renderer and it's not so clear how to use
it in general workflow.
I'll think more about this things to the end of week.
Ejner Fergo wrote:
> Hi François!
> Heh, that is good to know :)
> Hope to see it back soon again!
> Best regards,
> On Wed, Aug 17, 2011 at 6:24 PM, François T.<francoistarlier at gmail.com> wrote:
>> its in is personal todo list already ;)
>> I already punish him for that :D
>> 2011/8/17 Ejner Fergo<ejnersan at gmail.com>
>>> Hi Sergey!
>>> I was happy to see that you included the sensor patch into Tomato, but
>>> having tried a newer build I see that you made some changes (removed
>>> sensor height and vertical FOV).
>>> I understand by one of your weekly GSOC mails that you wanted to
>>> simplify the camera data workflow, but I feel disapointed that you
>>> removed the option to acces the vertical FOV ('data.angle_y') through
>>> the camera properties. As I have tried to explain many times on the
>>> patch-tracker, the vertical FOV is important for exporting the camera,
>>> and for importing cameras from other apps. During my tests and writing
>>> the Channel (.chan) importer/exporter, and atleast with FBX (most
>>> likely Collada too), 'data.angle_y' is essential to get the correct
>>> focal length with both export and import. Now this is removed.
>>> Blender is in many ways a complete pipeline tool, but realistically it
>>> is/will be included in existing pipelines among other tools, and here
>>> sharing camera data is very important, like Blender<-> Nuke (which is
>>> why I wrote the chan script, and hacked on Matt's sensor patch).
>>> Removing these settings (sensor height and thereby the vertical FOV)
>>> seems too much of a sacrifies, to simplify the workflow during
>>> It's fair enough you want to simplify the sensor settings during
>>> tracking, but then why not just include the 'data.sensor_width' in the
>>> camera data settings as you do now, and have both sensor dimensions
>>> (plus angle_x/angle_y) in the camera properties? What is the deal with
>>> removing the sensor_height anyway? If people find these values
>>> confusing, isn't that why we have all these camera presets now? Also
>>> why is there 2 preset folders for camera data?
>>> I hope you will reconsider the removal of sensor height and vertical
>>> FOV, as this is not just about making camera info seem simple, but how
>>> Blender will fit in mixed software pipelines, and generally be more
>>> Ejner Fergo
>>> Bf-vfx mailing list
>>> Bf-vfx at blender.org
>> François Tarlier
>> Bf-vfx mailing list
>> Bf-vfx at blender.org
> Bf-vfx mailing list
> Bf-vfx at blender.org
With best regards, Sergey I. Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-vfx