[Bf-vfx] Focal length constraints usability

Wed Aug 28 14:22:25 CEST 2013

Interesting. At first I was thinking that having the min/max set to equal
the given focal length would imply that it is fully constrained - but if it
only does that when the constraint is disabled, all it will do is provide a
good way to see what the values represent. I like this idea. I assume you
mean that the focal length should be clamped to the range because we still
need a starting point.

I'll do this and keep it in the solve panel for now - my feeling is that
perhaps refinement should be a subpanel of Solve, like Tracking Settings in
the Marker panel. Making it a completely separate panel would mean that you
set options in one panel and then click solve in another. Really,
refinement settings are part of the solve settings. Making it a subpanel
would mean it stays out of the way until the user needs it.

Again, thanks for the help with this. :)

Joe

On 28 August 2013 13:12, Sebastian König <koenig.sebastian at gmx.net> wrote:

> After a little talk in irc we found a solution.
> I think it's important that the user understands what the values of
> min/max represent. So they will always be visible. Above them you have the
> checkbox to enable the constraint. If it is disabled the min/max field
> always display the current focal length value. Once it is enabled the user
> can then change the values to anything he wants, and that will be the focal
> length values that are used for tracking, and they will override the focal
> setting in properties panel entirely.
> In terms of UI it would be nice to have them as a column, similar to the
> keyframe settings above.
>
> We were also thinking of maybe moving the refinement tools to own panel,
> because it starts to get a bit crowded in the solve panel. But no decision
> yet.
>
> Cheers!
>
>
> Seb
>
>
> On 28. August 2013 at 14:10:18, Joseph Mansfield (sftrabbit at gmail.com)
> wrote:
>
> Great feedback, thanks! In some ways I like the idea of having a separate
> "estimated focal length", but in addition to the UI inflation problem, it
> also might be confusing as to whether the estimated or real focal length
> property is being used. Would the estimated focal length be used when
> refinement is enabled? Or only when the constraint is enabled?
>
> I definitely agree that the default values shouldn't be 0.0 and 0.0 - that
> was a mistake! If you hover over the fields, it tells you the units they're
> in, which match the units chosen for the focal length in the properties
> shelf. Is this also confusing? We preferred this to having separate unit
> selections for each shelf.
>
> Sergey - is your suggestion with the clamping that if, for example, min
> and max are 18mm and 24mm but the focal length is given as 26mm, it would
> first move it into the range to 24mm before starting the solve?
>
>
> On 28 August 2013 12:37, Sebastian König <koenig.sebastian at gmx.net> wrote:
>
>> I think I would prefer absolute.
>> Because either I set a fixed focal length and solve for that, or I use
>> focal length and let blender do refinement (both options are what we had
>> until now).
>> Or, and that would be the new one, I know the focal length must be
>> something between 18 and 23 or so. In that case i would simply set these
>> values and then let blender figure out the refined focal length.
>> So actually Sergey is right and we can make it totally independent from
>> focal length setting.
>>
>> And how about trying to save some space in the UI?
>> Min/Max values could always with update with the focal length setting and
>> display the same value. And if I want to use different min/max constraints,
>> i simply change the values and they will be used. That way we could avoid a
>> checkbox.
>>
>> Seb
>>
>>
>>
>> --
>> Sebastian König
>> Schenkendorfstrasse 45
>> 04275 Leipzig
>> Germany
>> +49 176 20319318
>> www.3dzentrale.com
>> koenig.sebastian at gmx.net
>>
>> On 28. August 2013 at 13:25:33, Sergey Sharybin (sergey.vfx at gmail.com)
>> wrote:
>>
>> Thanks for the feedback, Sebastian!
>>
>> We might do it so min/max are totally independent from focal length, an
>> could be set to any value. Then, when we start solution, focal length gets
>> clamped to hat range internally (no user action is needed for this).
>>
>> Also, you didn't tell your opinion about using relative option. Which
>> mean, instead of having absolute min/max you'll define mm/px delta from
>> focal length set in camera panel, and focal length would be refined in
>> range of [ initial_focal_length - delta; initial_focal_length + delta ].
>> Does it seem more clear for you?
>>
>>
>> On Wed, Aug 28, 2013 at 4:23 PM, Sebastian König <
>> koenig.sebastian at gmx.net> wrote:
>>
>>> Hey!
>>>
>>> Great to hear it is getting closer to be trunkified!
>>> I just tried a test build from 3 days ago from graphicall and noticed a
>>> few things, related to workflow.
>>> Having never really tested your branch or really knew what it is about I
>>> think it was a good test what a user would think if he first sees the
>>> constraint options. :)
>>>
>>> So:
>>> - Having the two values set to 0.000 first was a bit strange, because I
>>> didn't know what the values represent. If the values will stay in mm, then
>>> maybe it would be nice to have them at the default focal length at first.
>>> 24mm for example
>>>
>>> - After I figured out what the min/max values are, I wanted to test how
>>> they work. I have set the min value to 18, and then tried 23 for max value.
>>> But because i didn't change the default setting of 24, I couldn't change it
>>> to anything smaller than that, which makes sense of course, but felt a bit
>>> weird. So I guess i would rather like the expanding way of dealing with
>>> that.
>>> Because let's suppose I know the focal length is something in between 18
>>> and 22. If i see the constraint setting I would think that that's the place
>>> where I can control the refinement. But if I don't touch the focal length
>>> setting in properties panel, I cannot set the max value to 22. So I think
>>> it would be nice if focal length in that case would just switch to 22, the
>>> max setting.
>>> Or, if i know it's something in between 30 and 35, the focal length
>>> would switch to the 30, the min setting.
>>>
>>> - Right now I have to look in the toolshelf and the properties, to the
>>> left and right of the screen for dealing with this. I think it would be
>>> nice to have it all in one panel. So the camera data in properties could
>>> still have all the settings for focal length etc, but since trying to guess
>>> the right focal length and setting the constraints for it now becomes more
>>> of a tool itself, there could be a setting for estimated focal length in
>>> the solve panel. Below that you have the 2 min/max settings for upper/lower
>>> threshold. If you set the estimated focal length bigger or smaller then the
>>> min/max settings below, it could expand accordingly. Because the 3 settings
>>> are then very close together it becomes more obvious to the user how they
>>> relate and what happens.
>>>
>>> - the question is then still what happens if the user changes the focal
>>> length value in the properties. But in that case I think it could just
>>> override the estimated focal length.
>>>
>>> I agree with Sergey, it does get a bit crowded, and what I just
>>> suggested would probably only make it worse. But rearranging the buttons is
>>> maybe not that big of a problem.
>>>
>>> I hope that makes sense. Can also discuss with Sergey on irc, maybe I
>>> can make these walls of text more clear there. ;)
>>>
>>> Cheers!!
>>>
>>> Seb
>>>
>>>
>>>
>>>
>>> On 27. August 2013 at 20:58:18, Joseph Mansfield (sftrabbit at gmail.com)
>>> wrote:
>>>
>>> Hey everybody,
>>>
>>> I'm getting my focal length constraints work ready to commit to trunk
>>> but I have a couple of things to ask about how the interface should work
>>> before doing so.
>>>
>>>    1. The current minimum and maximum fields take absolute values (in
>>>    either mm or px). Would it be more useful to provide an interval (say ±5%
>>>    or ±2mm)? If so, the next question is irrelevant. Perhaps both options
>>>    should be available, if it would be useful.
>>>    2. I currently have it so that, only if the constraint is enabled,
>>>    the focal length intrinsic in the properties shelf cannot be adjusted
>>>    outside of this constraint. Sergey has pointed out that the constraint is a
>>>    tool property and shouldn't restrict any other property. So here are the
>>>    other options:
>>>
>>>
>>>    1. Expand the constraint whenever the focal length is changed to
>>>       outside the range.
>>>       2. Allow the focal length to go outside the constraint, but give
>>>       an error if a solve with refinement is attempted.
>>>       3. Don't have any restriction at all (if you attempt a refinement
>>>       with the focal length outside the constraint, the given focal length
>>>       doesn't really mean anything.
>>>
>>> So, please let me know what you think. Thanks!
>>>
>>> Joseph Mansfield
>>>
>>>
>>> _______________________________________________
>>> Bf-vfx mailing list
>>> Bf-vfx at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-vfx
>>>
>>>
>>
>>
>> --
>> With best regards, Sergey Sharybin
>>
>>
>> _______________________________________________
>> Bf-vfx mailing list
>> Bf-vfx at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-vfx
>>
>>
>
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20130828/0de689e2/attachment.htm 