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

[Luke Wenke]

> Hi,
>
> Yep, manual text & tooltip text are not clear enough. It would help me
> most if you can just provide the text that clearly explains what
> Blender does here! No need for long explanations, just propose an
> improvemnt. :)

Ok, here are some suggestions: (note that it may need to be improved by
other people)
(p206 in Blender 2.0 manual)
==================
St Field (TogBut)
Normally, the first field in a video frame begins on the first line. Some
frame grabbers do this differently!
==================

Proposal:
==================
LoField (TogBut) [or LowField]
By default, Blender treats video textures that use fields as being upper
(odd) field first. If LoField is enabled, the video texture will be treated
as lower (even) field first, assuming the "Field" toggle button is also
activated.
==================

The tooltip:
currently - none.

Proposal:
==================
[LoField] or [LowField] <- new button names
---------------------------
Tooltip:
The video texture is lower (even) field first. (Default: upper (odd) field
first)
[The second half is implied anyway, so it could just be:]

The video texture is lower (even) field first.
==================

>From the 2.0 manual (page 207)
==================
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)."
==================
What I said earlier:
The tooltip repeats that first sentence. 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.
The button could be renamed to Fie/Frm
The tooltip could be: "How long (in rendered fields) a video texture frame
is displayed for".
The tooltip and button is hard to think of. I don't know what to suggest for
the manual.
I think it would be easier to explain if it was called "SlowdownFactor" -
the button could be "Slowmo" - and the values could be halved. So if the
value you put there used to be 7, the new value would be 3.5. Unfortunately
they involve half numbers though, rather than integers. But it is much
easier to explain... 3.5 means 3.5 times slower than normal speed - so each
frame of input video lasts 3.5 times longer in the output. I haven't seen
the code, but in an earlier message I tested the playback rate of the
animations and that's how it worked. (Currently you've got to set Fie/Ima to
*7* to get the input video to play 3.5 times slower) (BTW, a Slowmo value of
0.5 (Fie/Ima of 1) means things go twice as fast... which is fairly
straight-forward)

> Video technology is not simple at all... and not many people understand
> the full power of what Blender offers here. In NeoGeo we did 90% of our
> animation work for video, all for very picky professionals who demanded
> quality resembling what comes from their best cameras.
As I say a bit later, you'd have to export the blender renders into video
files then output it to the vcr using a separate program wouldn't you? And
that other program would ask you what field order the video file is...
anyway, I agree that video technology is pretty complicated...

> As said before, the terms used in Blender stem from experience with
> them. 'Even' and 'Odd' fields were normal words in our environment.
> That doesn't mean we have to stick with it, I'd rather comply to
> internation standards, like terminology Sony Broadcast uses or so.
Sony has taken over Sonic Foundry and their fairly popular video editing
program, "Vegas Video". That program only talks about upper and lower field
orders. Same with Adobe After Effects which is a fairly high-end video
editing program. Many places on the internet will tell you that DV is lower
field first.... they don't tell you whether that is odd or even.
It seems that people working in broadcast still usually talk about things
being odd or even fields... but in the computer industry it seems that upper
and lower is mostly used, and often odd and even aren't mentioned at all.
BTW, in order to export the video to your TV, I think people would normally
use a different program... they'd import the video file (and specify the
field order of the *video file*) then do "print to tape". Is there any other
way? I mean can blender directly access video out video cards? For DV, I
think it is always lower field first though lately I've just being setting
blender to even/upper and getting the video program to convert it. Since the
users have to use these other programs (that would usually mention
upper/lower and sometimes/often not mention odd/upper) then I think people
need to know if blender is rendering it as upper or lower field first. (etc,
etc)

> > "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.
> Wrong! Our clients wanted to have stills from our animation work a lot.
> Rendering with 'x' will give a superior quality image over doing a
> 'freeze' in video, that only displays a single field. Only needed to
> use when stuff is moving of course.
I thought field rendering with an x would be the same as progressive
rendering.... it would be the same resolution, and I thought the
anti-aliasing jitter would be exactly the same...  But I've tested it now
and the images are slightly different (one shade lighter in some places,
according to the eyedropper). I guess this would be due to it being
(slightly?) better image quality. Maybe the manual could say something about
that.

- Luke.