[Bf-vfx] Tomato camera sensor changes

[François T.]

2011/8/18 Ejner Fergo <ejnersan at gmail.com>

> Hi again Sergey,
>
> > 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.
>
> This concerns the rendering in Blender, not the camera. As the Sensor
> display option showed with the patch, the camera can have a larger
> vertical FOV than what is rendered. Btw, this sensor display option
> doesn't make sense without a sensor height.


> > 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.
>
> I'm sorry I don't understand what you mean? "All the rest parameters"
> in the camera settings is sensor dimensions (width/height). What is so
> confusing about that? It's rather simple really, so what needs deeper
> thought?
>
its easy to understand when you know what you are talking about, but for
most user, filmback or sensor size... well first they don't even know that
param exists and if so, you can do a poll I pretty sure most of them won't
know what it does affect.
But I agree with you, it is not a reason to hide it entirely. Sergey is just
looking for a nice way to put it so it doesn't get to confusing for people
who don't use it much. Talk to many 3DS Max or other 3D packages user
(beside maya) about filmgate and you'll see what I mean ;)



> > Having access to vertical FOV isn't so big issue -- it easily could be
> > read-only property which will be used by exporters.
>
> The vertical FOV, as you know, is defined by the sensor height, so we
> need to input this. Preferably the actual dimension as before, or with
> a device aspect.
>

yeah but the heigh can be guessed by the width and the pixel ratio, that's
what he meant by having params working together.
No matter if you change one or another it will always affect the others.
width, height, image ratio, pixel ratio


Why have the vertical FOV as a read-only property? Are importers not
> as important (no pun..) as exporters? The Channel file format uses the
> vertical FOV, so this should be able to be written to. The FBX format
> also uses the vertical FOV both during export and import, so having
> this as a read-only property is not so helpful.
>

I agree with that :)



>
> > 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.
>
> Again, Blender internal render only cares about the horizontal FOV.
> Why should the camera and IO with other apps be punished for that? I
> really don't understand why you think it is confusing to have both
> sensor dimensions available? We have presets, even a Blender one which
> I added, for people who don't know/care what these values are. To
> those who do know, both sensor dimensions are available for
> practically all cameras (even sensors defined as 1/1.8", 1/3", etc.
> have tables converting them to mm). General workflow will not be
> affected for 99% of all Blender users. Tell me how otherwise.
>
> > I'll think more about this things to the end of week.
>
> Thanks, I really hope you revert back to the sensor patch. It had all
> the basics we need: sensor_x/sensor_y + angle_x/angle_y
>
> Best regards,
>
> Ejner
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx
>



-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20110818/75a85a48/attachment.htm