On Sun, 15 Oct 2000 16:39:42 -0700, newvideo@amug.org (Bill Davis) wrote:
>In article <39e91015.1573311@newsstand.cit.cornell.edu>, d_ruether@hotmail.com wrote:
>> On Fri, 13 Oct 2000 21:02:25 -0400, "Doug Graham"
>>
>> >There's a new Apple codec out that corrects the earlier problems.
>> I'd like to see the results of 10-generations of
>> rerenderings...;-)
>10 generations of re-renderings?
>That's like asking to judge someone's cooking based on what it tastes like
>‹ after a week out in the sun!
>If you're regularly working with 10th generation stuff, drop me a line, I
>can probably help you organize your work flow.
No - the point is, if 10-generations of rendering shows very
little change in image quality (Raptor shows very minor
color errors only...), it is probably safe to assume that
a few generations of renderings (common for work in
Premiere, without resorting to After Effects...;-) will
not degrade quality noticeably, so it may be used "safely",
especially if the render times are reasonable...;-)
>> >As for color correction and long filters, ANY single stream rendering system
>> >is "too slow" for these, on a regular basis. Real time systems are the way
>> >to go if you need to filter/color correct.
>And, of course, it's arguable that you'll ever NEED to color correct if
>you simply learn to light and white balance properly.
But I shoot events on location, with little gear and set-up
time, or I assemble from stock footage, or use multiple
non-matching camcorders, or.... Sure, a Hollywood production
may not need (but probably gets...;-) image corrections.
I prefer an inexpensive editing solution that permits
control over the final image, made economically in time
also. The original point was that FCP lacks the ability
to make these corrections with reasonable render times, so
it is somewhat limiting in what one can do with it (unless
one is VERY patient...;-). I can do variable-sharpening with
time, correct color and exposure shifts with pans over
windows etc., correct unlike camcorders to match better,
correct slight color matching problems with different
shooting times, etc., etc. - all with render times that
are short enough to make these operations practical...
>BUT, remember, even so called "real time" systems are typically limited to
>two streams or two streams and an overlay channel. As soon as you do any
>significant layering, real time BECOMES render time. Since even
>single-stream systems are "real time" in cuts only, and since typical
>simple dissolves and the like render so quickly as to be little problem,
>the REAL advantage of today's so called "real time" systems falls in the
>narrow range of "two stream" projects like hackneyed "video in a window"
>stuff, correcting for MISTAKES made in shooting, and doing overlays like
>super'd ID's, bugs and logos. Other than badly shot footage, I'd bet that
>the other stuff comprises about 10% of the videos made out there. So this
>is the REASON to pick one system over another? Don't get me wrong. Real
>time is nice. But as a necessary feature to make a system "usable" I just
>don't agree at all. You just have to put your head into a "do it WELL"
>space rather than in a "do it FAST" one. And I'd argue that WELL will make
>you MUCH more money than FAST.
Yes. I suspect that my shooting style is FAR different from
yours (as in still work, some people lean toward studio-type
controlled-conditions work, others toward fast location
"grab" shooting [my preference]). For those who prefer to
control things during editing rather than during the
shooting, a reasonable compromise between an expensive
editing system that does permit some real-time operations,
and one that is impractical for all but brief lengths
of image modification, is here - and it is also cheaper
than either of the extremes (real-time, or FCP...;-).
>> I agree, but 3-6:1 render times are acceptable, even for use
>> on a regular basis (I do it all the time), but 24:1 is
>> quite impractical for any but emergency use...
>I respectfully totally disagree. If I do something complicated enough to
>justify that much rendering, you can BET I'm charging the client
>appropriately. It's amazing how LITTLE rendering bothers me when the
>client okays a GENEROUS dollar and TIME budget.
It's nice that you can... (and can get away with soaking the
client by using a slow-rendering system). May I suggest
moving to a Pentium 75, with Lumiere? (It renders ALL
the footage, so it should be slow enough to collect
fortunes from ALL your clients! ;-)
>> One can turn out great stuff with a cuts-only editor, but an
>> editor with impractically long render times limits the type
>> of work one can do with it
>Flawed logic. One person's "impractically long render time" is another's
>"cool, I get to take some time while this is rendering and THINK about how
>to make the project better." In fact, I think if MORE people had to render
>more, they might also THINK more and put out less crap. Then againl,
>that's probably just wishful thinking! : )
I refer you to the solution above... It seems that by your
view, VERY slow render times provide the advantages of
being able to charge more, and of providing more time
for contemplation...;-) I guess you may find FCP with the
G-3/4 slow enough, though, to consider it as a worthy
substitute for the P-75 with Lumiere...? ;-)
>Enjoying the discussion...
Likewise, I'm sure...! ;-)