#PAR Block Size for 1.27
31 messages in this thread
Has anyone else noticed that whatever value you set Block Size to, it has no
effect? Apparently now the only determining factor is Q. I'm just curious to
know if this matters to anyone else.
John
Yes, it's bizarre. The Block Size seems to make no difference at all. Any
idea what's up?
– John
John:
I just finished up a ton of animation last week and the BLF works the same way
it always did here. ie. I get away with 250 until my drive gets over half
full. Then I must switch to 240 for the next quarter drive capacity and
finally at 220 when working in the last quarter capacity of the drive. I
always set the QF at 23. If what you say is true are you setting your BLF to
maximum now?
Don, >> If what you are saying is true are you using the maximum BLF now?
Would I lie to you? <g>
Try a BLF of 400, (that was my last effort) just for the heck of it. I tried
several combinations and none of them made any difference. Looks fine as far as
I can tell but of course one does wonder what's going on.
John
REP 124427 L;John Mateer 100116,343;PAR Block Size for 1.27 John,
>> Any idea what's up? <<
Must be a new undocumented Auto BLF feature. <g>
John
John:
I tried a few different BLF's and visually could not see any difference.
Functionally I got no strange effects like image tear or corrupted images, etc.
Have you or has anyone out there had a problem with shelling out of 3DS to
operate the new 1.27b PAR.EXE? Version 1.0 still works without a problem, the
new version gives me a beep, no error message and simply doesn't work. I do
not get anything but the C: prompt. I thought that conventional memory was the
problem but a clean config.sys with almost 600k free doesn't work either.
Bob
Bob,
As I commented to Don, I have noticed any adverse side effects and as far as I
can tell, though I haven't really pushed it like an animation I did with an
explodeing sphere, the image quality looks less artifacty. (There's a new word
for the mutant animator dictionary. <g>)
I've got my PAR on a networked server which doesn't run 3DS so I really don't
know how the PAR works that way. I have noticed that the new version, as its
loaded high, requires more memory ie /B:1800 as opposed to /B:1500. You might
consider changing your 3DS CFIG to allow PAR.EXE more memory as I imagine it
has to share memory with 3DS much like Ani Pro or another extended program.
Before I could get away with allocating just a couple of Mb of RAM and now I
need at least 5 for it to function properly. Actually it was similar to what
you describe, I got a blank screen or I got just the top portion of the menu
and sometimes it would freeze or lock up.
If you haven't tried CFIG386 I'd give that a shot. Hope it helps.
John
I left the block limit set very high while messing around to see what effect
it had, if any, on image quality. I hadn't noticed any difference so I left
it. I was working on deadline for a local TV spot. We had to call DPS to find
out why our animations were not playing. They would start off fine but when
the images began to get complicated, ie. dramatic light changes, complicated
effects, lots of motion etc.. the animation images turned to many colored
squares and other corrupted looking junk. When we manualy scrolled through the
ani the individual images seemed fine. Upon closer inspection the individual
fields were corrupted looking to verying degrees.
DPS asked me to check my block limit setting and sighed. I checked, told him,
he said set them somewhere around 220 – 240 for the micropolis 2217. I do not
recall the exact explanation but it went something like this – the drive will
record all the information that the limit setting will allow. BUT it cannot
manage that much information fast enough when playing the animation back, at
least on my Gateway 486-66. I recopied the tga's to the PAR with the BLS set
to 240 and have had no problems since thank you.
ComWorks
Communications, Inc.
Randy,
Thanks, I'm aware that the recommended block size should be in the 220 – 240
range, but so far I've been running 400 with no problem and with a half full
disk. Course with a lot of pixel movement I could start getting crashes as
well.
John
Setting the Block Limit over 255 has no effect at all. The software is
limited to 0-254 for its block setting. The recommended block limit for the
Micropolis 2200 series drives it 240. For the first half of the drive you can
get 250 without any problems. (If your drive is not overheating).. When you
set the BLF to 400 and you get broken squares during playback, it means that at
that portion of the disk, the disk is not able to play back 255 blocks (the
limit), 30 times a second. I will leave a more complete message at the end of
this thread.
Brick,
I'm not having any problems but its interesting to note that the limit is 255.
I suspect that my current work is just not pushing the BLF and causing me
problems. I put it back at 250. BTW as faster drives come out, will you have
new drivers to take advantage of the higher transfer rates, or is there going
to be a limit based on the compression processor or transfer rate through the
drive cable?
John
John you can do some sampling calculations in simple arithmetic to determine
what you can achieve. I've done this with some 10 frame animations and compare
the *.ani file size with what the uncompressed size would be. At a BLF of 250
QF of 23 settings I get about 11-13 to 1 compression ratios. At 240 it runs
12-14 to 1. This has been pretty consistent.
Using the lower QF for rotoscope the ratios vary between 16 – 20 to one. Every
frame grab is different.
Interesting, you and I have the same question about the "software" limit.
Did you ever get the TBC IV ? I just landed a 90 second animation job last
week that will have 13 rotoscopes moving on the screen at the same time. It
will be mapped on each page of a magazine look using Schreiber page turn and
the cover will have the logo use Python. The background will also be a video
so I guess this will classify as 14 channels. I'm going to need the larger Mic
drive for this. Unfortunately, I will not have the luxury of my network to
render this monster since I'll need to import files from the PAR drive and
render them right back to the PAR to get everything to fit. Any thoughts for
logistics? <G>
Don,
>> Interesting, you and I have the same question about "software" limit. <<
It is an interesting question whether its a software or hardware limitation. At
255 that would imply an 8 bit compression ratio, which would explain why the
Max is going to use two drives, one for each field, to obtain a lower
compression ratio, as the minimum compression is being applied to half as many
pixels with fields. Which would suggest a maximum of 7.5 Mb per second
throughput. If this scenario is correct then the only way to get lower
compression ratios is to build a disc array like the Abekas and share portions
of the picture on multiple drives to approach something on the order of an 8 to
1 ratio.
No, I never did get a TBC IV. I opted for the Exabyte instead, as a) I can
reverse the process and send a post house a beta sp tape and have them send me
individual YUV frames for rotoscoping on tape which I can download as needed;
paint and put back on another tape without losing the original, b) its an
excellent backup system, c) I can store large amounts of pictures (5 gigabytes)
@ for $12 a tape, d) its fast and the tapedrive is networked so with multiple
machines there's little delay. e) Picture quality is not compromised. Now if I
could just find a paint package that will import YUV files without haveing to
convert. The process is fast on a Pentium and in a way has benefits in that you
don't get the frames confused but… The new Adobe Premiere for allows you to
do this, but wouldn't you know it… its for the Mac. Maybe I can convince Ron
Scott to support YUV. <g>
John
Don:
Another thought for you – if you get another 1.7gig drive for the PAR, remember
that it is a standard IDE disk drive also! There is nothing from preventing
you from running it on the PAR for certain projects, and then plugging it into
a generic IDE controller when you need the DOS disk space for a different
project. Disadvantage – you'd have to reformat to switch, but that shouldn't
be that big a deal, either, if you can plan it out by the project.
Greg Pyros
When the new fast drives are generally available we will support them
immediately. The PAR internal transfer rates are very fast, faster than any
available drive technology right now, so supporting any of the new faster
drives shouldn't be a problem.
Thanks Brick, for getting in on this thread. One question I still have about
this BLF "software" limit of 254 is: If I obtain a new drive that performs
faster transfer rates than the current Mic 2200 series (currently vaporware)
will the software automatically recognize the higher settings if I enter it.
eg. 280? Well, now I have another question. Are there any problems you would
caution us to if we would have two drives on the PAR as D: and E: wherein the
drives have different performance levels?
My opinion is that the animation quality is near "lossless" with 250 and QF23.
I try to work my animations in the first half of the drive to get this. What I
would like to achieve with the faster drives is being able to grab live video
at higher QF than 14 or 15. There always seems to be some artifacts visible in
the video rotoscope files because of this lower QF. Any thoughts on this?
When the new drives become available it will probably mean an upgrade of the
PAR.EXE software. Maybe not… hmm.. I will let you know, maybe we will add it
to the current software and set some hidden switch so that the BLF can be set
higher if it recognizes a new drive. If you are using two drives with
different performance specs like a Conner CFA1080a and a Micropolis 2210a, then
I would always render to the conner, using the Micropolis drives 240 BLF. Then
copy the animation to the Micropolis before you go to tape. That way your fast
drive always remains empty (or nearly) and optimized. Most of my projects are
in the short < 1000 frame range, so I render to an old Seagate 500 meg drive
and then copy the anims to the Micropolis. Where you will have problems is
with captureing live video, you will have to do the video capture on the fast
drive, then maybe copy it to the slow drive for rotoscoping, etc.
Try lowering the video level in the TBC-IV before you capture video, you will
probably find that you will get higher QFactors that way. You can always make
up for the dimmer video in software unless you are using it for a background
and trying to match frame it back to tape. The problem with most video capture
is that you are digitizing the extra high frequency noise caused by the tape
itself. This shows up as video detail (electronically speaking) and the only
way around it is to bandwith limit the video (throw away all the detail) or to
increase the bandwith of the capture (wait for a faster drive).
Brick
For the moment I'm planning to use a Mic 2217A with a 2210A and the speed issue
shouldn't be a problem. The way I figure I will need about 1.4 G of space for
the roto files and the 2210A will be used for the output that will only take up
about 120 Meg. Now, if the PAR could only be used on the network for network
rendering of this project.
We don't have a problem with the match frame because I got the writer to keep
the story line so that at the time we go from animation video it's a cut to a
new scene in live video. Makes life easier.
Randy,
I've just been experiencing *EXACTLY* the same problem with my PAR, that is
animations starting out playback properly and then flaking out part way
through. Especially where there are big color changes…..
The problem seems to be related to block setting being too high. The strange
thing is that when I was using the original PAR software (1.01?), my block
setting with the 2217 drive was set reliably to 250. Not a single problem!!!
As soon as I installed the 1.25 & 1.27 software, the block setting had to be
reduced to 220. Has anyone else experienced a difference in required block
setting between the original PAR software and the newer versions?
Also, one other problem I've been having is that when attempting to EXPORT an
animation file from the PAR to individual .TGA files on a DOS drive, I keep
getting frame 0 being repeated throughout the entire numerical sequence of the
TARGA files (i.e. imag0050.tga is exactly the same as imag0000.tga). However,
if I copy the files individually by name from the DOS prompt, they work fine.
Later,
-Jeff
Jeff –
I've had the same problem – although every 30 to 60 frames or so, I get a new
image. I didn't realize that copying using DOS was an option. I had copied out
two sequences from the PAR UI, then used the shareware Namegame utility to
rename the targas so that I could join the two, then used Windows to copy them
back to the PAR drive. I had assumed that the problem was caused during the
copy back – I'm pleased to hear that using DOS for the original copy from the
PAR drive will correct it.
Thx for the info!
bob
Regarding your BLF setting: I have not done anything different here and I
still use BLF of 250. You might check how full your Par drive is getting.
With mine I MUST set the BLF to 240 when the drive is over half full. Also
when was the last time you optimized the drive?
Hi Don,
I frequently optimize my drive, so that shouldn't be the problem.
Regarding how full the drive is; of the 1.7gbyte drive, I usually had about 500
megs left free. BLF setting of 250 seemed to be O.K. at this point with the
1.01 software.
Since I installed the 1.27 version, I've had so many corrupted animations, that
I've eventually deleted almost everything. There is currently 1.3gbytes free
on the drive, it's optimized, yet it still won't let me record reliably at a
BLF of 250.
I'm considering formatting the drive, to clear up the problem, but I don't know
if that would make any difference.
Thanks for your suggestions,
-Jeff
Reformatting may just do it but don't ask me why. I was forced to do it
because of the bug in the 1.25 install procedure. It is curious that you're
having this problem and I'm not; but, my other thoughts are not pleasant
ones. ie. The MIc 2217 A has a history of running very hot. This might be
shortening the life of the drive. The good news is that Mics are 5 year
warrantee and they do honor it. You may buy a small 3 inch fan and direct some
air over the drive to cool it down. I'm planning to buy a second drive for the
PAR for roto files and I also plan to add a dedicated fan to cool the drive
bank. I've been holding out for the next level of faster drives but recent
increase of roto business may force me to get the drive sooner. I just don't
like adding another heater to this room. My AC doesn't keep up anymore. <G>.
Don,
I've got two 1.7 Micropolis 2217's (one SCSI and one IDE). They sure do run
hot.
I took your advice and set up a small, 6 inch fan which blows directly into the
computer (with the side panel removed). The fan cooling is very effective as
the drives don't even feel hot to the touch with just a slow stream of air
across them.
Alec Jason
BTW: Is is OK to use RG58 cables for short run video purposes? For some reason
I've got lots of RG58 cables and just a few 59's. They do seem to work fine.
Thanks for the results on your fan test. I will be doing the same here. I
have lots of fans in the ole junk box.
You can use RG-58 which is 52 ohm coax for video if you don't mind some ringing
(looks like very subdued ghosting) in the video signal. <BG> If you must use it
it can be used to hook up deck monitors or anything else that does not actually
handle dubbing signals. For the price of cable why add artifacts to the video
signal by mixing impedance?
Don,
I'm ONLY using the RG58 cables for monitors and such things. I'm running the
actual component video signal from the PAR into a special breakout cable which
connects to the camera connector on a BVW-35 deck.
BTW, I know you like high tech stuff: A TV show has lent me a real nifty item:
an IR Thermal Viewer. I've played around with one of these some years ago but
the technology has dramatically improved. This little unit looks and operates
very much like a small camcorder. You just give it a minute to warm-up and then
you look through the viewfinder and, with a few simple adjustments, you can see
all sorts of interesting things. I used it find the hot spots on the
Micropolis: the hottest thing on them are the two small square chips at the
front.
I also found that the Viewer will let you see through (into) walls. I can look
at the gypsum walls in my house and clearly see each stud and each nail! This
unit also has a video out and a freeze-frame button. I only get to have it for
a week; it rents for $1,500 per week. Sure like to keep it.
Alec Jason
Alec:
What does the thermal viewer output look like when aimed at a person?
Greg Pyros
Greg,
Once you adjust for the backround thermal radiation, a human body shows its
relative hot and cold areas defined simply by luminescence: the dark areas are
colder than the light areas (or the opposite if you hit the reverse button).
The face shows the hottest areas along the hairline (my wife has bangs) and the
colder areas are the sinus regions adjoining the nose and under the eyes with
the tip of the nose being the coldest. The hands show that the fingertips are
the coolest.
My daugther had a friend over and I went out of the room and told them to place
a finger on one of the wooden Marimba keys and then I came in with the viewer
and quickly found the one key with a "hot" spot. Then they had me touch a key
and they'd find it. Boy, I'd like to keep this thing!
I'm a scientific/investigative consultant to a new Learning Channel TV series
and they sent me the unit because they have some video tape from a group of
"scientific" supernatural investigators who claim to see ghosts with the
Thermal viewer. I can easily duplicate their "ghost" images and they're coming
to videotape me on Thursday demonstrating how it can be done.
Alec Jason
The camera sounds interesting. I had one of these IR cameras back in 1969
using what was called a Tivicon tube. It was so sensitive to IR that I could
shoot video at night and pickup the trees and shrubs in the yard. It used a
standard survelance camera and I just had to rewire some of the power supply to
adapt the tube. I'm sure the technology has much improved since 1969 <G>
Yes, this new viewer is extremely sensitive. It does work like an image
intensification device. As you probably know, unlike the "night vision" gear,
the IR unit does not require any visible light at all. You can look out in the
absolute darkness and see the grass, trees, shrubs, cats, etc. It would work
great in a cave, too.
Alec Jason
Now's your chance! Videotape all of your walls and you'll never need a stud
finder again!
– J
>> Videotape all your walls and you'll never need a stud finder again! <<
Jack, I resent that comment. I don't raise horses and I'm not that kinda guy.
Alec Jason
<g>