#Super Black
36 messages in this thread
We're trying to find a good setting for Superblack in 3DS3. We're rendering
straight to Betacam SP in Y, R-Y, B-Y through a Grass Valley Transcoder and
we're using a Vista board. We have the animation created over a black
background. We want to key the resulting render on tape over another tape
source through a GVG 4000 digital switcher, when does a rather nice job in this
type of key. However, on the waveform monitor both before and after the render
blacks are still running too low. There simply isn't enough separation between
the blacks and a zero black level to get a good key. Note that this is a very
hot image on an HLS scale: flames and metallic letters. Yet The waveform shows
blacks falling below 0 ire. Base level black on the final rendered animation is
7.5 ire. This is with superblack on and set to 30 in the config file. How can
we control this? We need a separation of 30 or 40 ire to get a good key. Other
systems we're used permit setting a superblack level at 0 or -40 ire, but
apparently this graphics card is not capable of this.
This is something that pops up every once in a while and we expend a lot of
effort trying to solve it, without success. We're lucky since most of our work
is full frame and not keys.
Also: is there any way to split the alpha channel and send it to disk while
sending the full frame color display out to tape. We can't afford the disk
space to render 350 to 450 megs of graphics to disk first for each animation.
Also: is there any way to send the alpha channel out to tape without sending
it first to disk. Right now if the client turns around and asks for a traveling
matt of a finished animation (like today) we have to take the existing
animation file, turn off all the lights, turn all the materials to flat white,
and then render that out to tape. It takes a fair amount of time since there
are still lots of calculations to do. Other systems permit output of the alpha
information separately.
-Thanks, Robb
Robb,
<<We're trying to find a good setting for Superblack in 3DS3. We're rendering
straight to Betacam SP in Y, R-Y, B-Y through a Grass Valley Transcoder and
we're using a Vista board. ………… but apparently this graphics card is
not capable of this.
This is something that pops up every once in a while and we expend a lot of
effort trying to solve it, without success. We're lucky since most of our work
is full frame and not keys. >>
Wow, been there, tried that…! We fought this for some time (just as you have
it sounds) and the answer the way it was explained to me is that the super
black created in 3DS is only for use with video post options.
<< Also: is there any way to split the alpha channel and send it to disk while
sending the full frame color display out to tape.>>
If you find a way let me know, when we need to get the increased differences
between levels we are rendering a separate animation with objects that are
white and it's attributes are set to matte objects (like you are doing). For
now we are outputing to Beta SP and compositing our special effects on our new
AVID system with Cosa's "After Effects" software.
Hope this helped, sorry it isn't great news.
Jim Beyer
with COSA? boy that's a slow way to go. Our stuff will go out to a digital
online room which will do it all in real time but it's a pain to have to go
back through the animation and reset all the materials and lights. And then if
you forget something before rendering… Then too is the time to render the
traveling matt this way. The animation we just completed took 11.5 min/frame.
Resetting and rendering the matt took 2.5 min/frame. We do a lot of full frame
full color animations that take less than 2.5 min/frame. Doing the matt this
way is still using all the geometry of the original hence the time. At least we
switched rendering to 16 bit instead of 32 bit. Still, it's only an 8 bit
image.
Now why would super black be for only VP procedures, you don't need it since
you're working with a full alpha matt channel in 32 bit rendering. The whole
point of super black is for keying through an online video switcher. OK class,
who has the answer?
-Robb
Hey Robb and James,
I'm not sure if I'm missing something here but to me the obvious
answer is to render with Alpha Split on and to your framebuffer simultaneously.
The 24 bit image will be displayed and can be
put to tape. The alpha or "matte" image will go to disk.
If disk space is a problem you can put a line in a batch file in VP
which will delete the 24 bit image but not the alpha image.
Then instead of rendering matte objects just create an IFL file
with the Alpha Split images and put them to tape. That will be
your matte.
Does this do it?
John
Hi John. Long time no chat. How are things?
John Tissavary | LUNA cie, inc
Hey John…
>> How are things? <<
No complaints. <g> DGate is getting rave reviews and I'm
getting an EISA board. Guess you know what that means. <g>
How goes it with you?
John
Things are going well. I've been "out of circulation" for a few weeks getting
some training, but I'm back to regular production as of monday. There are some
pretty wild things on the horizon for my company.
I got some of the Dgate sell-sheets – they look pretty good.
What in the world could you possibly want an EISA board for? <sarcastic g>
John Tissavary | LUNA cie, inc
>> I got some of the Dgate sell-sheets <<
I hope you got some of that green stuff with it. <g>
>> I've been "out of circulation" for a few weeks getting some training, <<
Well I've been pretty much out of circulation… period. <g>
I'm sure the training was a good idea. I'd guess it was intense.
>> What in the world could you possibly want an EISA board for? <<
I know, it does seem kinda wierd. <g> They say its great for cruising the
Internet, we'll see.
John
The problem is: Under all circumstances the full color image goes to disk as
well as the alpha-channel file. Yes, disk space is a problem. A standard
animation for us would require between 350 megs and 1.5 gigs. Most of the
available drive space is filled with frequently used applications and we are
not will to constantly offload and onload applications to provide drive space
for files that are unwanted in the first place. Please note that this is a
dedicated graphics workstation.
There is no combination of software settings within the render procedure
which will permit what we really want: full color to display and alpha to disk.
While this should be a fairly simple software switch, it is not available.
We have also noted several anomalies within the rendering software settings:
You can set Split Alpha to On while Render Alpha is off (nothing happens). You
can have both Render Alpha and Split Alpha On when set to 16 bit ( again
nothing happens). Actually it seems reasonable that one should not be able to
select a switch combination that does not make sense to the system (e.g. Split
On while Render Alpha is Off).
The idea of using Video Post seems to be the only possibility but a
tremendous workaround. It also seems very risky. While we use VP a lot, In my
limited experience (bear in mind that I'm the director/editor not the computer
animator) video post is a complicated solution and one risks deleting files
that may be necessary elsewhere or later. How do you put a delete command in VP
anyway?
At the same time this thread began asking questions about Super Black. How
would Super Black relate to and be necessary in VP. After all, keying is what
the alpha information is all about. Super Black should relate to external
experiences, such as keying through a switcher.
-Robb
Alpha is about keying???? I don't think so.
Alpha is about transparency. One of its uses is keying. The manner in which
3DS does Super black is confusing to those of us in the video profession as we
define super black differently than the way 3DS does. The rendered output from
3DS "black 0,0,0 with super black turned on is always 7.5 IRE in a calibrated
frame buffer. In video we would expect super black to take the 0,0,0 black to
0 IRE for the key. 3DS does not do this. What 3DS super black does is create
a wider spread between RENDERED black objects and the 0,0,0 black background in
the scene. This spread can be specified in the 3DS set file and has a default
of 15, I recall. This will help in preventing holes in shadows and other
rendered blacks that are layered using alpha transparency.
The only way I know of to generate a value of black below 7.5 IRE is to adjust
it in a procamp with the pedestal or black level set-up before feeding the
alpha to the key input on your switcher.
Have you ever done any animation using the alpha key? I have done still
graphics but never animation. If you have, what hardware configuration do you
use to create this traveling key? Seems to me you would require two frame
accurate VCR's and a third VCR for the background video. I have also played
around with some alpha channels in the Fast Video Machine that are used to
perform an alpha transparent wipe pattern between the two channels during an
A/B roll.
<<Alpha is about keying???? I don't think so.>>
it sure is in video post production. The alpha channel gives the video switcher
the information it needs to make a key hole which is then filled with whatever
you specify. You decide if the alpha information creates a solid key or a
partial key (transparency). A good linear keyer in a good switcher can take the
alpha information and interpret it into a clean key, whether it comes from a
character generator, a graphics system, a DVE or even off of tape. In the real
world most keys (and their alpha information) are solid rather than
transparent. The transparency is what causes trouble when the switcher cannot
read the alpha information well. Then you get solids when you shouldn't, or no
keying at all, and that results in a crummy inage.
<<we define super black differently than the way 3DS does.>>
so who's right in their definition, the new guy (3DS) or the industry that's
been around 30 years longer?
<<In video we would expect super black to take the 0,0,0 black to 0 IRE for the
key>>
actually, I'd prefer Superblack to be -10 to -40 IRE, we get a much better key
that way. It works best with a difference of about 40 ire between the black and
the lowest level in the image itself.
<<What 3DS super black does is create a wider spread between RENDERED black
objects and the 0,0,0 black background in the scene. This spread can be
specified in the 3DS set file and has a default of 15, I recall.>>
Uh, Huh. That's what it claims in the manual, but what setting creates what
level of separation. We've fooled with all sorts of setting and still can't get
much if any change. If it needs to be up around 200 then I really don't see the
point.
<<The only way I know of to generate a value of black below 7.5 IRE is to
adjust it in a procamp with the pedestal or black level set-up before feeding
the alpha to the key input on your switcher.>>
That's work only if you're feeding a pure alpha signal, which doesn't need it
since it is made up of pure blacks and whites, and shades of gray to give
transparency. If you drop the pedestal on a color image you''ll pull the video
level down as well. Pulling the video level up again will change the contrast,
and the look of what one hopes is a carefully made image, besides, dropping the
pedestal will not create a difference between lowest black and the next lowest
level in the image.
<<Have you ever done any animation using the alpha key? >>
Lots, Thousands over the years, sometimes hundreds in one show, so it's very
important to us.
<<Seems to me you would require two frame accurate VCR's and a third VCR for
the background video. >>
That's how it's done and that's the rub, you have to pay for an extra machine
in the session and you have to have a switcher that can handle keying
information from a tape. Basically you have one tape with the color image (key
fill), another with the key information (key source) and one or more tapes with
other background images. The edit controller will synchronize it all to the
Master deck. A traveling matt (or key in video terms) is an exact replica of
the color image to be keyed, but it is all blacks and whites matched to the
color image pixel by pixel. On the switcher, the key source is selected as a
tape input (say deck C) on the Key Buss. The key fill is selected as the color
image on tape (deck A) on the Key Buss. On one of the main ME (mix effects)
busses a source tape (B) is selected, and this becomes the background when we
set the switcher to Key over tape B. Of course if we're really clever we could
be dissolving or wiping between decks B and D at the same time that we're
keying (and inserting a DVE move from deck E over all this) as well as a
downstream key from the CG all before a master fade to black. All of which it
gets hairy in the online room.
OK, so we have the traveling matt. It is an exact B&W copy of our animation.
Since it matches it will be in the same position and be the same size and shape
as the color image. The B&W punches the hole in the background video and the
color animation fills that hole exactly. Now it's expensive enough and
complicated enough that we like to try to go a different route which when it
works saves the cost of a deck and a lot of set up. A luminance key works when
there is a great enough difference between standard black (7.5ire) and the next
level in the image. A pure white CG is a classic example. It can be keyed all
by itself because there is a good 90 ire of difference between the black
background and the white foreground. The same can be done with color images.
However, you must set the lowest luminace in the color image to no lower than
30 or 40 ire (depending on the switcher) on a 7.5 ire background. That can be
very difficult with some images. The trick then is to artificially lower the
black in the background, to 00 or even lower. Then the difference between that
black and the next level is even greater and a better key is possible.
Considering the explanation of Superblack in 3DS I expect it to work as a lower
end buffer for the dark regions in my image limiting to a specified level (20,
30, 40ire) whatever I set. The the resulting color image should have a great
enough luminence difference to key without an alpha matt (and saving the cost
of an extra machine in online). Some of the 3DS images work and some don't. The
alpha information in 3DS works perfectly, but a traveling matt right now
requires rending the entire animation as an alpha split to disk. We're set up
(and have been for years) to go directly to component tape. I don't want to go
to disk unless I have to, it just takes up valuable disk space and isn't
necessary. I certainly don't mind putting the alpha files to disk while I'm
rendering color to tape but I don't want to be writing a deleting thousands of
unwanted files. I just want to do Alpha split and tell 3DS to put only the
alphas on disk. From my point of view it seems like it should be easy enough,
but I'm not a programmer.
Thanks for the detailed description from one who does it. I will save your
excellent description for my references.
One thing I might caution you is when you read certain terms in 3DS such as
"video post" "Super black" "keying" "rotoscoping" etc. don't always assume
these terms have traditional video definitions. They are similar terms but
have been redefined by Yost group to more accurately describe the video world
as seen by the 3DS animator rather than an experienced video editor. This
doesn't make the definition wrong. It just adds new definitions to an existing
vocabularity. Thus, alpha in the 3DS arena is all about transparency, by
definition. Actually about transparency in layers of graphics files to be more
accurate. As a side bar: I once attended a lecture by Lon McQuillon. He was
asked a question about "Super Black" in a talk about the Ultamatte blue and
chroma keying. His [funny] answer was "Super Black??, I'll have to try a
bucket of that. Do you spray it on, brush or roll it?" <G>
>>><<The only way I know of to generate a value of black below 7.5 IRE is to
adjust it in a procamp with the pedestal or black level set-up before feeding
the alpha to the key input on your switcher.>>
>>That's work only if you're feeding a pure alpha signal, which doesn't need it
since it is made up of pure blacks and whites, and shades of gray to give
transparency. If you drop the pedestal on a color image you''ll pull the video
level down as well. Pulling the video level up again will change the contrast,
and the look of what one hopes is a carefully made image, besides, dropping the
pedestal will not create a difference between lowest black and the next lowest
level in the image.
I only meant that the output from 3DS will be at black 7.5 IRE. Super Balck
does not lower this when the _ALPHA_ channel is viewed from the frame buffer.
However, you can of course lower the blacks in this alpha file with the
procamp. This would in no way affect the color image blacks which would remain
at 7.5 IRE. Since I've never actually done alpha channel keying they way you
describe I'm not sure this lowering of the pedastle will have relevance. I
only originally mentioned it because I thought you were confusing 3DS
definition of what "super black" does and what you thought it should do.
With respect to your problem, I take it you use the VTR control function from
3DS??
I agree that this makes the recording of the alpha split rather difficult.
This is probably a wish list item. I don't see any way to record the color
portion of the alpha rendering to a VTR to save disk space while splitting the
alpha off to disk and recording later. I never used the alpha split when I
used the VTR function with 3DS for my diaquest board so I never ran into it.
Without going to a double rendering you would have to render to the disk both
files and then lay them to tape individually. FWIW: I spent two years
rendering and single framing from 3DS and found it was in my best interests to
render to disk, then record the frames to tape from disk. It prevented unusual
wear and tear on my VCR and tape. Also if something went wrong such as a
corrupted frame of a stretch in the tape I could just go back and re-record.
The lengthy rendering process was complete and the files safely on disk. Once
I had a confirmed tape I erased the rendered files freeing up disk space for
the next job. Even with this I still had trouble recording more than 1000
frames at a time due to tape stretch, wear and tear. I used a 7750 and a 5850
and the 5850 was far superior. Today I use a PAR and output to all formats and
do 30 times the quantity of work to tape.
<<The real scenario is to be able to save to disk the alpha split file while
recording to a VTR the main color file at time of rendering to VTR.>>
Yup, that's it.
We don't experience tape stretch with metal tape. We also don't get dropped
frames. For the occasional frame with a drop out we rerender the offending
frame. For highly critical applications we'll render to both tape AND disk.
However, we have such a large quantity of graphics software on each work
station that it is impractical to offload software to accept rendered files.
Rendering is only the last step in the process for us and it is again
impractical to work with nearly empty drives that are only waiting to hold a
few hundred megabytes of rendered frames at a later date. We have multiple
systems networked to both syquest and M/O drives on demand. But most of our
primary rendering is handled on an overnight basis and it works best for us to
simply run to tape. Saving the alpha split only to disk would save me both disk
space and the extra time needed for secondary rendering.
OK, so I understand your goal but still don't see what it is you have against
adding hard drive for your FxF operations. A 1 G western digital Mode 3 IDE
drive was selling last week for $560, MO. so cost can't be the issue here.
Curious about the metal tape issue and stretch. I had heard just the oposite
and have experienced some tape stretch problems with betacam SP when the tape
gets old, as in edit passes. It appears as a running or smearing of the
picture and diminished audio response from the linear tracks. This may not be
stretch but has been described by Sony rep as such. What's your opinion?
Your operation sounds impressive. Where do you work?
Cost is ALWAYS an issue. We have about 9 gigs of storage lying around here in
various formats. I have no desire to constantly add more, just to render more
graphics. The inclination is to hold onto the rendered frames until the client
has approved the final animation, and then hold onto the frames until it can be
run onto a house tape for demo reel stuff. In the end the frames would want to
hang around all too long, and then archiving takes up a lot of organization
time and tapes. It's a busy place. I spend too much on drives right now to get
more. We went through this for a long time when we used a service bureau to run
to tape. That was an enormous headache. I broke down and bought all the gear
necessary to render straight to tape: deck, controller, transcoder, waveform,
vectorscope, monitoring and switching. It was a good investment. Productivity
went up about 70%. We also tend to render more often for tests and catch a lot
of errors before the deadline. It also alleviated all the storage problems,
especially when there are several animation projects all at once. Then one goes
to disk and the other to tape. When we're really pressed for time we'll go to
tape with one machine while the other renders the last half of the animation to
disk. When machine 1 is done then we run the other frames from disk to tape.
The business with the traveling matt doesn't happen that often. But our
Symbolics is equipped to handle it the way we want (when it's working, which it
isn't). It's just another wish list item I suppose.
We're a film and video production company. But we're a little different
than most, especially here in the Midwest. We own all the equipment necessary
to control post production and keep it inexpensive, while not owning an online
room. We have EMC digital non-linear editing, a Dyaxis II digital audio
workstation, two PC graphics workstations, and a Symbolics graphics workstation
(dead as a door nail). We do complete projects in film or tape or we do a la
carte work for other producers. We have post production wired so we spend an
average of only 1.5 hrs in online (as opposed to 2 or 3 days).
We never reuse tape. It just isn't worth it. The client buys the Betacam SP
tape for the project, it's shot and then archived. It's loaded once into the
NLE system, run once in online and then archived. Graphics tapes may have
several projects strung on them one after the other, but in 7 or 8 years of
using Betacam SP metal tape we've never had one problem. Drop outs may happen
on a bad lot, but that;s extremely rare and more likely to be a problem for
field tapes.
The next step for us will be a DDR especially for multilayer compositing.
Then storage will be a problem again, especially versus cost.
-Robb
!^NavFont01F0007MGHHOC4F94A
<< polished-up wish.. >>
got it..
Hi!
Realy, the way to go is to use those alpha channels… We've had to go through
all this for some projects. If we want to output something to be keyed, then we
use
Yost's Clamp IXP to restrict the range of the luminance in VPost, using a
matte.
But this not realy an ideal solution.
Sometimes we bypass this process by fiddlin' with the ambient light level
(start with 60) to restrain our blacks.
Since we always render to disk (we use an Abekas A65), we enforce matte
generation for all our projects. 8-bit files are not that big…<g>
Let us know if you find an elegant solution!
Daniel
RSB Video Inc.
Montreal
The elegant solution is to use the alphas, just render them to tape, a perfect
traveling matt. It's just the matter of not being able to save the alphas
alone, without the corresponding full color images. I can do it with other
systems I have so I know it can be done. I'd rather do it in a compositing
system but that's more money.
We use the SP because it's a convenient traveling format. It's certain that
not everyone has an Abekas, or can transport files, and going to composite D2
has no advantages over component beta sp. D1 is a little silly, for the expense
thought I've been toying with Abekas 601 file formats since there is some
interesting software that will utilize it. But then I could create the Abekas
files and use something like Diver to convert them to TGAs to be run to tape.
Who knows?
-Robb
>> It's just the matter of not being able to save the alphas alone,
>> without the corresponding full color images.
You CAN do an alpha split. If you don't need the color portion, a batch file
run from the video post module can probably delete the prior frame's image
while saving the alpha file.
> >> It's just the matter of not being able to save the alphas alone,
>>> without the corresponding full color images.
>>You CAN do an alpha split. If you don't need the color portion, a batch file
run >>from the video post module can probably delete the prior frame's image
while >>saving the alpha file.
That's how "alpha split" works by saving the alpha file to disk. However, it
will not do so without render alpha on, 24 bit on, and render to disk on (even
if you ask nicely). And again the color file is also saved. It is a tremendous
workaround to have to write a VP to delete files. And in deleting files one
runs the risk of deleting something necessary. I just want to render and save
to disk ONLY the alpha files.
>> I just want to render and save to disk ONLY the alpha files.
Ahhh ha! That sounds like a good wishlist item.
<< >> I just want to render and save to disk ONLY the alpha files.
Ahhh ha! That sounds like a good wishlist item.>>
got it.
Hi Jonas:
To be sure you have it right, The real scenario is to be able to save to disk
the alpha split file while recording to a VTR the main color file at time of
rendering to VTR. This way the alpha split file can be single framed as a
second operation to a second tape for the alpha key or traveling matte. I
believe this is what Rob Harriss was trying to do as his disk space was to
small for the size of all those main color files. I had mentioned to him that
most people were rendering totally to disk first and then recording disk to VTR
later but the issue with him is he didn't have enough the disk space.
Robb,
>> It is a tremendous workaround to have to write a VP to delete files. <<
No its not, its very easy. You just create a small batch file that says:
del c:\3ds\images\pix*.tga
then add a new line in VP and list it in the Process section.
Thanks, John for popping in. I have just started to use some more ops like
calling batch files for VP to do file manipulation. I'm starting to get a mind
set to tackle the scripting language too. Robb has a pretty impressive system.
I think he would be a good candidate for a PAR or MAX, don't you? At any rate
QT for the final run to beta SP should be high on his priority list. Hearing
him talk about all that single framing even for tests just makes me cringe.
Glad I don't do it anymore here. His problems have pointed out a weakness in
3DS's split alpha function and I hope Gary has been taking notes. People who
do traveling matts for keying are indeed a rare breed. Speaking of rare
breeds, where has Paul Lind been lately? I'll bet he had some solution for
what Robb was trying to do.
My impression of the alpha split issue is that Video Post makes it possible to
easily get rid of the .tga file that you've written in case you just want to
collect alpha files.
– G
True, but since he was recording the color file directly to VTR would he be
able to save the alpha split file to disk?
I am going to answer this myself as I just looked. He can do it! As you put
the option to save the file to disk in the record to VTR window. However,
since I nolonger have my diaquest board I can't try it, so I have to ask can he
render, save the file to disk, lay the color file to VTR, and finally erase the
color file with a batch file called from the VP as a final step. He only wants
to save the alpha split file on disk, not both. Additionally, he does not want
to render twice to accomplish this.
Don,
>> I'm starting to get a mind set to tackle the scripting language too. <<
I wondered how you'd feel about that. I think you'll find it worthwhile as its
a tremendously powerful feature and I expect that some people will concentrate
on scripting moves etc. much like what was done for the ADO, so you'll have a
pre-built set of moves etc.
Whether you get into it enough to creating your own on a regular basis, knowing
how it works will be give you invaluable insight.
>> I think he would be a good candidate for a PAR or MAX, don't you?<
Sounds like a perfect candidate, and probably the PAR would be the better
choice in his situation. Get the frames off and yet still have them for
archiving etc. I'm with you, I can't imagine how anyone can work that way. FXF
is not exactly perfect as we've discussed and I've had more than a few
occassions where a frame was dropped or glitched. The hassle of resetting 3DS
to re-render the frame and drop it in (not to mention tracking that particular
frame down) is more than enough reason to either invest in more HD space or get
a PAR. At least is you have the frames stored you could do it through DOS.
Pesonally I thought this whole thread was a non-issue and was suprised a week
later to find it still going on.
John
>>Pesonally I thought this whole thread was a non-issue and was suprised a week
later to find it still going on.
Yes, well that is partly my fault as I was fascinated with his excellent
knowledge of the alpha keying and traveling matte issues but equally fascinated
that with all that setup he had he was still fixated on a what I consider a
total archaic and inefficient method of recording animation.
Nope, I have no interest in a PAR. The minimum standard for a next level for us
is a DDR with everything at 601. Nothing we've seen coming off the PAR was
worthwhile. Our turnaround on animation is too quick to have frames sitting
around, waiting for various people to view them, besides I don't like wasting
design time in the middle of the day laying frames from disk to tape. We have
no problems with the tape based system, and three other uses for the tape deck
(which we would have to have around even with the PAR) so it is a much better
value than the single use PAR. The primary reason we don't already have a DDR
is since we are not an on-line edit facility our end product (in this case
animation and graphics) must be portable. Abekas D1 files aren't terribly and
I'm not in the mood to buy a D1 deck. The SP works just great and can be read
by nearly every facility in the region. As far as archaic goes (the tape deck
is the one and only non-digital piece of gear in house) writing thousands of
files to disk and then writing routines to erase immediately wins on that
score. Why not have the program just do it right in the first place.
Anyway, this thread is about Super Black, or at least it was supposed to be.
I take it there is no real Super Black in 3DS as regards the real world?
!^NavFont01F000FMGH66JF0MJF4HK`C8B4
>>I don't like wasting design time in the middle of the day laying frames from
disk to tape.
Neither do I, that's why the PAR has improved my weekly output to over 30 times
the animation to tape in a week compared to what I used to do with single
framing. My animations never see tape until the final version. I render my
previews at reduced res for speed to the par and review motion, then when
everything's just right I render at full res for the final output. I only do
industrials through local broadcast with betacam SP component editing with the
PAR so it is adaquate quality. You should at least give Quick Pass a try
though. (I'm assuming you have a Diaquest controller, maybe not). Of course
you might find you have too much time on your hands, won't look so busy to your
boss and he just might give you more work to do in the same period of time.<BG>
Hah! I had a boss like that once. Everytime I figured a way to make the job
simpler he would just assign the other guy's responsibilities to me to do since
I now had some more free time.:( No extra pay, just more work.:(( Now I own
my own business! 🙂
True super black with 3DS? not as far as I'm concerned. As I said before, if
I need to spread the blacks lower I use the procamp. All my frame buffers
seem to limit the lower end to 7.5 IRE.
>>> It is a tremendous workaround to have to write a VP to delete files. <<
No its not, its very easy. You just create a small batch file that says:
del c:\3ds\images\pix*.tga
then add a new line in VP and list it in the Process section.
<<
Ok, that doesn't sound too bad, but you have to understand that I'm the
director and editor, not the CGI artist. Sometimes I have to did this stuff up
to eliminate time delays in delivery.
-Robb
!^NavFont01F0008MGC2HH61D524
>> Ok, that doesn't sound too bad <<
It really isn't. 3DS is marvelously flexible and has all kinds
of things built in to cover unexpected requirements. The presumption
is that there must be a way to do it and the question is "how ?" 🙂
Let me know how it works for you. Sometimes you need to allocate a little extra
memory with Phar Lap to make it work but if you can shell out to DOS from 3DS
you should be O.K.
John
>> Let me know how it works for you. Sometimes you need to allocate a little
extra memory with Phar Lap to make it work but if you can shell out to DOS from
3DS you should be O.K. <<
I gave the message to the animator for him to try. I'd still rather have a
software switch for "save alpha to disk?"
>>I gave the message to the animator for him to try. I'd still rather have a
software switch for "save alpha to disk?" <<
Well Robb I don't mean to offend, but this thing about an Alpha switch has been
going on for over a week and I think if this is your biggest concern you must
live a very charmed life. I really wonder if you have any idea what your
animator does or goes through in the course of making animations! Maybe its the
editor in you that brings out this intense interest in having another switch.
<G>
Take care,
John
>> Maybe its the editor in you that brings out this intense interest in having
another switch <<
I'm not the one who wants another switch – the switch is already
there. As it stands the software switching sequence is out of logic –
you can select render alpha and then the alpha is not rendered. You
can select to split alpha but nothing will happen. In these cases the
switches should be grayed out or otherwise inactive. That's my point.
As far as choices go, yes, I do want to be able to select alpha
alone, or send alpha alone to disk.
>> but this thing about an Alpha switch has been going on for over a
week and I think if this is your biggest concern you must live a very
charmed life <<
Well, actually, in a real world setting it was extremely important.
The client asked for a traveling matt after the animation was
completed and shipped. It cost an extra 10 hrs of rendering time and
a day's delay. It's only a guess but having to render the full
animation as whites and grays took longer than rendering the 8 bit
alpha image alone. I'm the one who has to face the client.
>> I really wonder if you have any idea what your animator does or
goes through in the course of making animations! <<
Actually I believe I do, coming from an animation background and
training. But we both have better things to do than watch a machine
sit and render at the last minute.
!^NavFont01F0017MG50HHB6MIwHJ6CMJCCHK5518F2