[Bf-funboard] (ton) Re: Odd/Even Upper/Lower fields...

Luke Wenke bf-funboard@blender.org
Tue, 7 Oct 2003 18:10:04 +1000


Hi ton,
I know some of this is repeated, but I'd like to just reply again to your
message. Even if this is beyond the scope of Blender 2.30, maybe you could
save this message or something so that these changes could be made later
rather than these problems always remaining. People mightn't even complain
about these things, but I think that is because they aren't constant
hassles - once someone has figured out that even=upper and odd=lower, and
input videos are upper by default, and StField means the input video is
lower field first, etc, the problem would no longer bug them. So they
wouldn't feel a need to go to all the trouble of complaining. (And it is a
lot of trouble to complain about this...)

I've been reading through the Blender 2.0 manual. For the StField button it
says this: (page 209)
"Normally, the first field in a video frame begins on the first line. Some
frame grabbers do this differently!"
This seems to confirm my earlier post that said that video textures are
upper field first by default. This button allows lower-field first images to
be used. (The video frame begins on the second line)
As said earlier, StField has NO tooltip at present. Perhaps the reason why
people haven't complained about it is that they don't use it at all or if
they figure out how to use it, they don't think it is a problem. Maybe
StField means "starting field"? or "second field"? I think it should be
called "LoField" and the tooltip could be "Video texture is lower field
first".
I think some rarely used features should have the text changed a bit even if
no-one bothers complaining about it. As far as the documentation goes, the
user would just see that there is no StField button that is mentioned in the
old documentation.... instead there is an unmentioned LoField button. And by
reading the tooltip they can see what that means. In video programs (where
the field-based video would come from) it would tell the user whether it is
upper or lower field first... but if they read the documentation, they
mightn't be sure whether StField applies or not (it makes no mention of
"upper field first" or "lower field first" - instead it talks about
low-level stuff).

>From the 2.0 manual (page 209)
Fie/Ima (NumBut)
"The number of fields per rendered frame. If no fields are rendered, even
numbers must be entered here. (2 fields = 1 frame)."
The tooltip repeats that first sentence. But it is wrong (I think). That
number is the number of *rendered* fields per video texture frame. Or in
other words, how long (in rendered fields) a video texture frame is
displayed for. I know I was originally mixed up about this, but after you
explained I still think Blender is wrong.

BTW, if things have informative tooltips, I don't think it matters if the
documentation doesn't mention it. And documentation can be updated.

Blender 2.0 manual, page 238:
Odd (TogBut)
"This option indicates that the first field in a video frame begins on the
first line."

Basically that means upper field first, as I stated earlier. So the default
is lower, and the button could be renamed to Upper or Up. The tooltip could
be "The output video is upper field first".
BTW, many or most popular video programs don't mention odd or even field
first. They talk about upper and lower field first. The user can experiment
and work out what which thing in blender (even/odd) corresponds to what
(upper/lower) - this is quite difficult to do though, because the only way
to test it is to put the video onto a TV and see if it flickers when the
video moves - or if it is smooth.
The manual description of the button helps a bit - if you know exactly what
upper and lower field first mean (some users mightn't)... the tooltip only
talks about odd and even field first - nothing else.

http://www.mir.com/DMG/interl.html
"What are "even" and "odd" fields? That's crazy-talk. Even worse, it's
really ambiguous and confusing. Don't use those words."
(Like I said earlier, it is ambiguous because the first field could be
numbered 0 [even] or 1 [odd] - and apparently some people do number the
first field 0)

"x (TogBut) With "Field" rendering, this switches the time difference
between the two fields off (0.5 frame)."
Just to repeat what I said earlier, I don't think this feature is necessary
at all. Video programs can easily handle progressive (normal) frames, and
that's what the output of this is equivalent to (even if you reverse the
fields). The reason why it is slower is because the envmap is updated twice
per frame even though the frame only changes once per frame. (With regular
field-based videos, there are 2 changes per frame) Rather than modify the
envmap stuff I think it is better to get rid of the x. Maybe things like
shadows are also calculated twice per frame.

- Luke.

----- Original Message ----- 
> Hi,
>
> Let's not expand the scope of what we can do for 2.30.
> Especially questioning terms we use in Blender for over 5 years is not
> useful in the context of the current UI project.
>
> We only should remove now:
>
> - bad consistancy (to what is standard in Blender)
> - or very confusing wording we get complaints on a lot
>
> Further take into account that all documentation about Blender should
> remain usable at some level. We are producing a 2.3 guide in parallel
> to the release itself, I hope this remains manageable.
>
> Blender improvements won't stop after 2.3 of course. My proposal would
> be look at all wording in Blender after that. We also have the UI
> translation stuff still pending though...
>
> Further:
> - Fie/Ima = when you use an animated Image-Texture, it is the number of
> fields rendered before it loads the next Image as a Texture.
>    Set it at '1' to have one (texture)Image per field rendered.
>    This has nothing to do with Image-Textures that have fields.
>
> -Ton-