I'm sure Juan is looking very closely at what it will take in HD, protocol, support hardware, and will find answers. I know QuickStream is have more then it's share of difficulties with their streaming tapeless capture system and it only captures compressed DV.

I have always thought this will be the "killer" problem to overcome on this idea. As always, I wish Juan luck and hope his ideas are better then my instincts in this regard.

-Rodger

Juan, I wonder if you would be able to implement an aspect ratio (letterbox) function (like for 16:9 or 2.35:1 or custom aspect ratios) that would actually crop the images before writing them to disk to reduce data rate and storage requirements.

So, for example, let's say instead of capturing all 480 vertical pixels for each frame, you could only capture the center 270 or 300, etc if you wanted to, and have this reflected in the monitoring somehow. Of course, if you were to capture only the center 270 pixels, then your tiff frames would be a much smaller 720x270. At uncompressed data rates, that would add up to a lot of savings over time.

Would that be too hard to implement? I think it would be useful.

His posts didn't make any sense whatsoever with regards to the file system issue.
He said he was going to just write to the drive, not regarding the file system on said drive. Nonsense.
What do you make of it?
Juan, please clear this up !
-Les



<<<-- Originally posted by Obin Olson : les...how would Juan know how to build the box if he did not know what a file system is???? -->>>

Les
 

I don't mean to speak up for Juan, but the tone of your posts are leaning towards aggressive/argumentative. Juan has been an absolute professional in responding to posts promptly and informatively. You probably don't mean to sound this way intentionally, nevertheless, it comes off as somewhat negative.


es

I just want to nip any possible problems in the bud before they are ' show stoppers' as we say in the biz.

-Les

File system
 

Juan,

If you want the disks to be readable on both MACS and PCs perhaps you could consider SGI's xfs file system. Special FX houses are using this on their sans so that both MACs, PCs, and SGIs can access the same files.

As I understand it Preformat on disk drives is usually just the hard sectoring and low level format. The high level format as you know is somewhat O/S dependent. The NTFS Les mentioned is of course specific to windows NT and I believe XP. MAC OSX probably uses some variant of BSD (Berkeley Softwared Distribution) formatting. "Wine" from MAC 0S and Unix systems should be able to read NTFS and FAT PC files.

XFS has two advantages.

One) each OS can be setup to read XFS files.

Two) Xfs is a journalizing file system so it is easier to recover from
system crashes and other problems with the file system.

If the data rate goes up in the next generation (HD or uprezzed
SD) you might have to go to a raid 0 configuration.

I agree with some other posts that we should be patient with Juan on the question of what File system he is going to use

The program he wrote to use with his test capture device had no trouble writing Tiff files to the MAC file system. So I am not worried he can figure out how to write files to a disk from firewire or gigabit or SDI in any case.

I only suggest XFS for Juan's consideration. There are any number of reasons why he might take another direction.

I agree with Les. Filesystems are complicated beasts and you
cannot just write to disks and read it on a PC / Mac without
additional software.

Personally I would go with FAT32 at first as almost all direct-to-disk
options do. This does mean implementing a FAT32 filesystem
manager. I'm not sure if there is some free source we can find
for this. Otherwise I might be able to write such a system.

I would not go with another filesystem like NTFS or the proposed
XFS (at least to start with). For the following reasons:

1) Mac/Pc might not mount it per default. Mac's cannot do NTFS
and both cannot read XFS per default and need drivers installed
which adds to the getting read to use part

2) most other file systems like NTFS and XFS are much more
difficult to implement (especially in such devices) [especially when
they are journelling file systems]

3) you will also need information on how this filesystem works
which is not available for NTFS for example. I'm not sure if such
information is available for XFS. Such information is readily
available for FAT32.

One thing I'm also worried about is number of files in a directory.
Let's say you are recording a shot that lasts 10 minutes at the
default NTSC framerate of 30 fps. When you are recording in
plain TIFF files you will have 18.000 files!! I'm not sure what the
directory limit of FAT32 is, but that number of files in a single
directory is very slow on your computer and possibly on "our"
device as well. With such a system you at least need to use a
different directory for each recording you do.

The only other option is to use a movie format. This probably
means also writing a "codec" (uncompressed) for each system.

Or is there some "codec"/file format we can use that the big boys
are using as well?

stay away from codecs!

The only codec I know right now that can support Juan's mod is the new 12-bit 4:4:4 Quicktime RGB codec from Blackmagic for the HD Pro card. Other than that you'd have to use some 16-bit codec like None-16 etc., but then Quicktime doesn't work on Linux, so . . . the best bet is to use Tiff files like Juan is already doing.

I agree that FAT32 is probably the best bet-Although watch out-there's a 127GB file-size limit on FAT32 on OSX. I believe it has something to do with partition size limits on FAT32 and how they've been getting around those limitations using virtual partions, etc.

file system
 

Juan, with thanks to Rob Lohman for his informed comments,

FAT32 might be OK. Does anyone know the limit on the number of files? Of course it should be implemented so that one has access to 160Gb disks!

I have run up against a limit on both too many files and too many directories under UNIX however that was because I didn't allow enough space for the root partition.

I don't know exactly what the spec is for standalone "firewire" drives. I read that on a powerbook G4 you can press T at bootup to cause the G4 to emulate a standalone firewire drive. Details of what the MAC does should be available.

The benefit would be that people could use the powerbook G4 as a portable drive with the added benefit of being able to do a rough cut in the field.

When they got back from the shoot they could use the same trick to mount the G4 to their G5 edit system to read the edited files or the unedited files.

There is also a tool available for free from snell and wilcox {MXF} to encapsulate avi and other mulitimedia files with metadata so that the multimedia files can be handled by most filesystems. This would have to be applied after capture.

file systems, direct transfer vehicles
 

Juan, Rob, with special thanks to Jason,

Jason thanks for your helpful comments. Do you recommend the HDpro by blackmagic. Are their 12 bit in and 14 bit out more than hype?

I prefer the AJA HD capture device on paper because it has upconvert from SD to HD. I don't think the DECKLINK has this?

A 12bit quicktime would be nice though for high end film transfer work. Where can we get the none-16 codec?

So far there is no SDI format that supports more than 10-bit.

As far as a protocol for direct to disk transfer goes for HD I prefer dual link SMPTE 392 but its only 10-bit. Sony's high end 444 recorder uses this.

Quote from SMPTE site:
SMPTE 372M-2002: Television – Dual Link 292M Interface for 1920 x 1080 Picture Raster
This standard defines a means of interconnecting digital video equipment with a dual link HD SDI (link A and link B), based upon the SMPTE 292M data structure. The source formats for this dual link interconnection are the picture raster formats, and digital interface representations as defined in SMPTE 274M. The total data rate of the dual link connection is 2.970 Gb/s or 2.970/1.001 Gb/s. This dual link also supports carriage of the embedded audio, the ancillary data, and the ID of the stream.

Some have suggested fiber channel which is OK for storage but bad for networking (see):

http://www.broadcastpapers.com/asset/GigE%20vs%20FC.htm

Firewire 800 and Gigabit will handle uncompressed SD just fine. Uncompressed 10-bit HD might need multiple firewires or multiple Gigabit ethernets with possible syncronization problems.

There is a reason to go with Industry standards or to create industry standards. Maybe Juan can come up with something that becomes and industry standard.

HDSDI - Film transfers -applying log scale
 

Juan, Rob, Jason, Les, and listmembers,

Without buying the standard for HDSDI from SMPTE there may be details posted in the SMPTE journal see the following references.

1. SMPTE 292M, .Television.Bit-Serial Digital Interface for High- Definition Television Systems,. SMPTE J., 107:849, Sept. 1998.
2. SMPTE 274M, .Television.1920 x 1080 Scanning and Analog and Parallel Digital Interfaces for Multiple Picutre Rates,. SMPTE J., 107:837, Sept. 1998.

See also

http://www.broadcastpapers.com/dcinema/dcinema.htm

a 19 frame per second HSDL format has been suggested for
moving 14 bit depth images around a post production plant.

The advantages of applying a logarithmic scale to image data are highlighted. I suggest that maybe a 10-bit logartithmic scale is as good as raw 12 bit data?

Could a logarithmic scale be applied to the data at the FPGA in Juan's mod? Would there be a benefit to taking the log and sending the data 10 bit? This could save bandwidth and disk space.

Of course maybe 12 bit 444 would be nice too! No compromises.

Ok i just got back, so i'm trying to catchup! Here goes:

Joel:
That is a great idea, i totally forgot about that option. It is very easy to implement and i've added it to the list of features..i for one use letterbox mode all the time in the DVX, and a hefty amount of bandwidth and space can be saved. I will make sure to do it such that the user can pick the actual frame size.

Les:
I still stand by what I said: The firewire interface doesn't care what format the drive is, and this information is contained in the website i gave ya.

I think the confusion here is that some people want non-technical 'end user' information, and others want down to the bone technical info. I can't tell the difference of who wants what type of info just by a question.

From a user's perspective, it doesn't matter what FW800 drive you buy. Every FW800 drive in the market right now can handle the bandwidth. Just hook it up and go.

From a technical standpoint, we have to go back to what stephen was drilling into our heads a couple of weeks ago: there is no such thing as a 'firewire' drive. In essence, it has to be handled like if the firewire interface wasn't there, it is just a transport method. Think about SDI. Does it matter if what you have on the other side of the camera is a tape deck or a monitor?

The 'box' i am referring to, is the device I am building which will be mounted under the DVX100. And yes, there are specific areas of the FPGA dealing with the low-level filesystem duties, but i know little of the details because I am using megafunctions already available in the environment I am using.

For starters, I am going to keep it simple and do the exact same process I am doing on my experimental setup...it will be a single file containing the raw R,G,B frames packed together. At this point, the number of files will not be a problem, and in the case that the file system will limit this, we can always keep the raw format in one contiguous file.

During these days I am little more worried with hooking up the hardware. I already have all the physical parts for the prototype so all that will be left is FPGA configuration changes which are quick.

Blue Screen Test:
I could only find a (dark?)blue board but I do have it here so i'm going to try and do it now. One of my felines devoured a surface mount probe so i'm fixin things...

Juan

RAW is good!
 

OK, Juan,
Thats what I thought you were doing ( the right thing ) ... simply writing the rgb data stream to the drive in as raw of a format as possible.
You might want to reserve the first 200 K of the drive to be an index for the rest of the drives contents.
Call it a primitive file system, if you want.
Format of the data structure:
unsigned long START_block_number_of_stream,END_block_number_of_stream;
Then have a counter for how many streams you have in the table.
Each time someone shoots some shot, it gets a new table entry on the reserved part of the drive.
When a new shot starts , your BOX looks and sees where the next free disk space there is.
Don't bother with deleting files, and fragmentation, you don't need that anyway. The drive is like 'film' or 'tape' a sequence of contiguous storage. It's fast and simple.

Encode the data with a LUT and stuff three 10 bit colors into each 32 bits, ala Cineon. 10 bits is enough to get ALL the dynamic range off of film.

Now, you will have to write a driver to mount this drive on a computer to allow the users to get to the shots.
Not too hard.
On UNIX you can just use dd to read the sectors off the drive, and you could even just write a little shell script to decode the index and get to the shots ( takes ) !

I too am looking into preparing a camera system for feature work. Kind of like an independent film shooters version of the Viper. I'm looking at including the D.I. editing and color grading software package with it as well, all based on >8 bit source images. This will be more flexible than working with film and doing a Spirit HD transfer, since that locks you into color grading choices very early in the post process.

Beware of Sony paid assassins. They won't like this type of activity. It will upset their apple cart, so to speak. I don't think it's even on their radar yet, though!

-Les

Write a driver????

Please, no drivers, that takes everything out the "simple" category. I've used enough buggy drivers in my lifetime to know that if we can just keep it simple with firewire800, etc. then everything will be fine.

PAL
 

Hi all,

This is my first post. I have been following this thread from the very beginning. Juan - my compliments.

There has not been much talk about PAL. Juan, if I remember properly, you said that you had an NTSC chip camera with a resolution larger than NTSC (I do not remember the exacty resolution out of the top of my mind). Another reader noticed that changing your raw chart frame to NTSC resolution and then applying NTSC pixel ratio, one would have an NTSC frame with perfect rounded circles.

I am not sure if you had already noticed it, but from the same original larger raw frame it is possible to obtain a PAL frame: changing resolution to PAL 720x576 and then applying 1.066 PAL pixel ratio, one has a PAL frame with perfect rounded circles.

I am sorry if this is rather "silly", but it seemed to me that this PAL issue was never brought out.

Gianluca

PS: the inclusion of SDI output is definetly a good move!

Drivers are nothing compared to what the circuit design and fpga programming is needed for a project like this.
Firewire 800 or plain firewire drives need drivers or other custom software to make things happen.
Firewire drives are not video tape.
-Les

I agree that we should stay away from drivers at all costs. They
are difficult to write and even more difficult to maintain (in the
future).

So this leaves us with systems that are already supported.

I think Juan was talking about writing a SINGLE FILE for each
recording to a FILE SYSTEM. But correct me if I'm wrong. From
reading his post he seems to be talking about some functions
in the FGPA that already do low-level file system access?? If so
I'm wondering what the file system is (probably FAT32, keep
in mind that there is a 2 or 4 GB file size limit in that case as
well!!!! -> i'd say 2 GB if you want to support Mac's).

From searching a bit around it looks like the maximum file size
is 4 GB - 2 bytes. I could not find a maximum number of files
per directory or for the root directory:

" The root directory on a FAT32 drive is not stored in a fixed location as it is on FAT16 and FAT12 drives. On FAT32 drives, the root directory is an ordinary cluster chain. The A_BF_BPB_RootDirStrtClus member in the BPB structure contains the number of the first cluster in the root directory. This allows the root directory to grow as needed. In addition, the BPB_RootEntries member of BPB is ignored on a FAT32 drive "

So you can probably create new cluster chains unlimited. Ofcourse
I can easily see why this can create drastic performance problems
with lots and lots of files since you will need to traverse lots of
cluster chains as well.

But if it is indeed just 1 RAW file (possibly with a header to indicate
which recording format it is in, Juan?) this shouldn't be a real
issue.

The maximum disk size it can support is 2 terabytes. Some sites
also claim this is the maximum partition size, but I'm not sure
how this would work.

Juan: have you actually tested your setup with a drive mounted
to your device and then moved that over to your PC/Mac? It
feels like you are missing some crucial parts there.

how come you haven't been posting pics, juan?


And by the way, if I'm right, this mod applied to a pal DVX would give you an image around the size of 800x600. Just so you know.

Rob:
Yes, I was talking about a single file in the file system itself. However, I do have to point out that like I said before, this is not the part I am concentrating on during these days because it's just software and reconfiguration. My immediate goal is to have a prototype setup such that I can do instant tests and then start fiddling with the rest of the FPGA configuration.

Afaik the megafunctions I have deal with FAT16/32 and NTFS. I can get my hands on a lot of designs, but because of the nature of this application, I really would like to simplify the design as much as possible...if I use the megafunctions I have right now, i can probably complete it fast, but i will run the risk of having to use an even bigger and more expensive FPGA.

Rob, can you point me in the direction of some good PDF's outlining the details of FAT32 or NTFS? I'm betting that if I can implement just exactly the circuitry that I need to only write files, i can speed up things and keep the FPGA size to a minimum.
I can sit back and use the functions someone else wrote but it would take longer for me to reverse-engineer them and simplify rather than start from scratch and write something simple.

Juan

Juan: I can understand why you are not bothering too much with
this, yet. I would probably do the same. That's why we are
reminding you about it <g>

Are you saying that FPGA (which one was that again?) you are
working with comes with FAT16/32 & NTFS libraries? Are you SURE
NTFS is included? That would be very strange since NTFS is almost
licensed to no-one by Microsoft and there is no definitive guide on
the internet on all the technical details.

If they already have those libraries I would not start looking into
writing my own code. Writing file system code is pretty dangerous
and time consuming thing. If you can spare the room and cycles
for now just leave it at that to get it working first with drives.

We can always upgrade the code later if need to be. I personally
would much rather clean up working FAT32 code then create new
one from scratch.

Keep the following things in mind:

1) for simplicity I would not start off with NTFS or any other more complex filesystem. Stick with FAT32 for first release. We/you/someone can always add support for more file systems later

2) forget about FAT16, that does not support large enough files etc.

3) keep in mind that we should split/start new files automatically before we reach the 2 GB barrier (which seems to be the most compatible barrier)

Does your chip/code have any way to either give back date/time
and/or timecode (timecode could be generated, ofcourse). That
would be handy to use in filename generation (which people can
perhaps customize as well).

I'll see if I can dig up some technical detail regarding FAT32.

File system s/b compatible with MACOSX 10
 

Juan,

One thing to consider. Most but not all users will want to edit using final cut pro. So whatever file system is chosen, the file system should be mountable under Mac OSX10.

Don't know for sure what Mac OSX10 uses for disk format some BSD standard format? The file system underlying the GUI is Free BSD Unix.

Some users of course will want to access the filesystem chosen by Juan from Windows XP and eventually Longhorn (yikes). Some will be using Linux or SGI.

FAT32 doesn't make very efficient use of disk space and there is the 2GB limit on partition size. Nonetheless if FAT32 can be mounted on most platforms it might be a good place to start.

I still suggest looking into SGIs multiplatform xfs file system as
a long term solution or option. See sgi.com.

More on xfs (for those interested)
 

XFS runs only under LINUX and IRIX right now but can serve files to Windows XP using Samba. I know there is also someway for MACOSX (bsd unix) to also mount the file system (I'll look into this).

Don't know if Juan wants to implement an embedded Linux on a soft processor on the FPGA (sounds like a formdible challenge); however the advanges of XFS are highlighted in this IBM article:

http://www-106.ibm.com/developerwork...ary/l-fs9.html

See also:

http://oss.sgi.com/projects/xfs/faq.html

If you had an embedded linux xfs drive, you could run samba and netatalk to interface with macs and pcs see foote cone and belding section at:

http://oss.sgi.com/projects/xfs/xfs_...ture%20Company

If you had a fast enough satellite, wireless, or landline internet connection you could use samba tunneling to send your files directly to the editing machine harddrive!

See who is using xfs?:

http://oss.sgi.com/projects/xfs/xfs_users.html

For filesystems with many small files, ReiserFS is preferred. For
filesystems with lots of huge data files, XFS is the ticket.

See DKP Effects.

See also echostar (satellite television).

At another special fx house Moving Picture Company:

http://www.linuxuser.co.uk/articles/...he_picture.pdf

So I think in the long run Xfs is the way to go. Gigabit ethernet or SMPTE 372 dual link HD-SDI s/b the preferred transport protocol.

Firewire800 is of course capable for SD at 270mbps and 540mbps.
The main drawback is that the disks have to be located close to he camera.

Randall: please take the time to read this little FAQ so you can
create working links yourself. Thanks!

I'm not sure where you are getting your info from, but FAT32
can definitely have partitions large than 2 GB! It can go to at least
127 GB and possibly to 2 TB.

The file limit is 4 GB but most systems limit that to 2 GB. This is
not a real problem because you can easily split the capture over
multiple files if it reaches such a boundary. You will need to post
process the footage anyway so it is easy to include reading from
a batch of files.

Personally I would definitely not go with the native Unix / Mac OS
filesystems and XFS (for now) since it cannot be mounted on
Windows systems. I (and I doubt others) don't want to install
some unix box to get access to a camera.

Windows, linux & Mac OS X can read FAT32 partitions and file
systems. It is what ALL the direct-to-disk records for DV are
using as well. There is a good reason for that.

I want to take the harddisk I recorded on to a partner of mine
who has PC's and Mac's and be able to mount the drive. I don't
want to bring a unix machine with me.

What's wrong with splitting the files if they get too large? More
easy for archiving anyway (2x 2 GB or 1x 4 GB more easily fits on
a DVD for example).

You can always enable more advanced file systems later if
someone really wants to use it. For now I vote for simplicity
and getting it working. Everybody can read and work with FAT32
RIGHT NOW, out of the box.

I will find out what the exact limit is on the partition size for FAT32.

FAT32 details
 

I'm doing a bit of research and the maximum partition size seems
to be a bit of an unknown. Perhaps we should run some tests
if people have large disks lying around.

According to this interesting article (from a trustworthy source)
Microsoft has builtin a limit in XP to format FAT32 to only 32 GB
so people switch to NTFS. You can actually format larger partitions
under Windows 98 (and possibly Windows 2000). How stupid is
that. It's easy to include a small tools for Windows XP users
though. Most drives come formatted as FAT32 as well.

Update 1: it looks like Windows 2000 has the same limitation

" You cannot format a volume larger than 32 GB in size using the FAT32 file system in Windows 2000. The Windows 2000 FastFAT driver can mount and support volumes larger than 32 GB that use the FAT32 file system (subject to the other limits), but you cannot create one using the Format tool. This behavior is by design. If you need to create a volume larger than 32 GB, use the NTFS file system instead. "

Notice the 'by design" line. We can easily work around that.

Update 2: it appears one can download the FAT32 specs from Microsoft

FAT32 File System Specification

NTFS details
 

Juan:

Linux NTFS drivers?

Some NTFS technical info (menu is hard to see in the middle)

About NTFS

NTFS is something that wouldn't get my vote. Only Windows
supports it.

yes, please stay away from NTFS, that will basically alienate all your FCP users on OSX.

OSX can read an NTFS partition, as well as Linux (actually OSX is using the Linux open-source drivers), but it can't write to the volume. Also it can't mount an NTFS partition that's segmented into a couple partions.

Right now the maximum mountable FAT32 partition on OSX is 127GB, JFYI.

The other file system out there that OSX can read is UFS (unix file system), but I'm not sure how popular that is. So that's not really recommended either.

I'd say go with FAT32, but again, I'm not sure what to do with the 127GB partition size limitation under OSX.

file system
 

Juan, Rob, Jason, and listmembers,

Yes FAT32 may be the easiest solution to implement. I don't know however whether FAT32 has an ideal block size for recording a digital video stream. Fat32 will also eat up the disk faster than some other file systems. Large EIDE Disks are cheap now so why should we care.

My suggestion (admittedly more difficult to implement) would be set up the drive attached to the mod box as its own standalone computer (running embedded Linux). The xfs formated drive would be accessed from Windows and MacOS as a network drive
using SAMBA or netalink (running on the modbox). This would require a gigabit ethernet rather than a firewire connection.

The downside is that the modbox would have to be present when the location recording drive was accessed by the editing machine.

However, the camera has to be present now when downloading a DV file unless you have a DV deck attached to your edit machine. So this shouldn't be seen as a big disadvantage.

If one wanted to be able to plug bare drives into both systems, one would need to build a player interface box with embedded linux on the edit machine.

File transfers (assuming one had only one remote recording disk) would be relatively fast with a gigabit ethernet. Files could be archived on DLT if necessary.

links
 

Rob,

Thanks for the link to the FAQ.

Is vb enabled on this forum? I belong to a lot of email lists that don't even allow HTML posting (everything is plain text) so I inadvertently assumed listmembers might have to copy and paste if they wanted to follow a link.

I will use the vb tags with links in the future if they are necessary on this forum.

Randell: just do {url}link{/url} where {} should be []

FAT32 blocksize will not be too much of a problem since we are
only working with large files. Block sizes are basically only a
concern if you work with (lots of) small files.

Ok, it seems like there's some decisions to make here. I think FAT32 sounds like the best option because both mac and windows can access it. Sound good? I am going to avoid at ALL costs, needed any sort of driver to work the hard drive. My goal is to be completely plug and play, ready in NLE friendly format.

A driver IS needed if you want to plug in the raw capture device on the DVX DIRECTLY to a PC for capturing to the PC's drive.

About the blue screen shots:
I just now finished hooking up the 10-bit experimental setup back up, and took some test frames to verify everything is fine.

I need pointers on the lighting, and scene selection. Unfortunately, the 'scene' is right next to a sliding door and there is outside light coming in, so i might need to wait till dark to then fire up my work light and get a somewhat uniform lighting across the blue screen.

What I plan to do is to upload photoshop files with RAW separate R,G,B frames, and knowing that the green channel is a little different size, what are everyone's guesses on the perfect alignment and resizing. If several people do this separately, we are bound to get good guesses.

I will shoot a resolution chart which will also help with the alignment.

Post any suggestions now! :)

Juan

Links; Block sizes; Juan's File Design; xfx optimums; size
 

Rob, Juan

Links:

Thanks. I was able to click on my links w/o a problem. I included the urls in my post instead of naming the links because many people like to know where the link is taking them.

Block Sizes relevance:

The way I usually work in Maya and Prman I have one tif or other numbered file for each frame. So there _are_ a lot of files the way I work; however, a frame at 4k resolution is good sized.

Juan's File design:
If Juan puts all the frames in one file, I may need another application to parse his file (no big deal). If he uses quicktime or mov file structure.

Xfx block sizes:
Xfs block sizes can be from 512b to 64kb. For most applications 4kb is about right. Sometimes the journal and metadata are put on another drive to speed things up. The journal is always on a different partition than the data. Terabyte databases can be addressed since the addressing is 64bit.

Using robust off the shelf software [linux, xfs] although mor complicated) may allow a more capable and reliable system in the long run.

Blue Screen Shots
 

Juan,

You know to evenly light the blue screen. Hopefully you have a pure monochromatic blue (sometimes difficult to find).

Suggestion:
Try to avoid reflections of blue off the bluescreen on to your foreground.

Try to avoid having the foreground cast shadows on the blue screen. Usually the foreground and the bluescreen are lit separatey. The bluescreen is lit with very flat light.

The foreground can have key and fill and backlight. Use lights with the same color temperature 3200K. Kill any flourescent lights. Try to avoid shadowing the bluescreen.

you might include hard edges and soft fury edges and glass in your foreground objects just to see how difficult it is to composite.

Try an evenly lit and a cross lit foreground.

Ok, while it gets dark outside I have taken a frame of a resolution chart. I know it's off center, but I tried to align it such that the sides where parallel with the CCD edges as much as I could. This is intended to make R,G,B alignment as easy as possible.

Please try it out and post exactly what shifts and resizing you did in photoshop, relative to the original file. Then we can compare each other's findings.

These are completely raw, no alignment no nothing. Ignore the few speckles as usual.

http://expert.cc.purdue.edu/~pertierr/rez_RAW.psd

Are there any guidelines for testing with a resolution chart as far as camera positioning? I did this with the resolution chart about 2-3 feet from the DVX so I had to use a bit of zoom.

I noticed what seems to be a defect of the 3-ccd approach...the blue channel has a little different focus than the other two channels, probably because it is slightly farther away than the other two CCD's due to the prism design. The stuff we have to put up with. <g>

Blue offset
 

Juan,

The different focus for blue and red is specified in the standard for Prism blocks. Its called offset. The reason is that the lens
focuses at a different point depending on the frequency of the light.

Higher frequencies like blue are bent more and focus closer I believe. Longer wavelengths like red are bent less and focus farther back. The lens tries to compensate by using two different kinds of glass but there is always some residual differences in focus between the colors especially at the edge of the frame.

I think I posted the link to the european standard. I think the offset is something like 30 microns(different back focal lenght) for blue for a 2/3" block. The DVX100 uses 1/3" sensors.

Maybe panasonic didn't get the offset right or they are morphing the colors in their processing? The overall back focal length in air is something like 48mm (changes for 1/3", 1/2", 2/3", and 1")

I hope each camera doesn't have its own particular misregistration? I always thought ccds should have tracking adjustments but they are usually just glued to the prism block.

I need some more bluescreen pointers.

First of all, this is what i'm using. I've got a blue posterboard, and two work lights. The only way that I have managed to not cast shadows on the bluescreen is to locate the two lights on both sides behind the key object, pointing about 45 degrees at the blue screen. The problem is that the two lights are pretty close to the blue screen so brightness pattern can be clearly seen on both sides of the bluescreen...if i move them farther away, then it casts shadows of the key object. Im using a compressed air bottle as an object for now.

I'm thinking the ideal situation would be powerful lights with diffusers, but i don't have that...any suggestions?

Ok guys/gals, this is my first pathetic attempt. Like I said before, never done this before so i'm going just by intuition...attempting to isolate the object that is.

I have a problem with either the lighting, or the color of the board(or both) because the blue is coming out too dark, and I can't separate it from black.

Anyway, this is a scene with just the bluescreen and a bottle of those cool armor-all wipes.

What I did is I used the 'clear' feature in photoshop to get rid of the keyed selection, and see if I could get to just keep the object alone. It replaced the background with the back-color(white), and areas that were lit with the bluescreen also appear lit in white. There's also some transparency in the wipe so i thought that would make a good test.

I couldn't keep the black letters out of the selection, someone else can probably do a better job.

I need some brighter paint, and probably better home-made lights. Any suggestions from the chroma-keyers would be greatly appreciated.

http://expert.cc.purdue.edu/~pertierr/bluescreen0.tif

http://expert.cc.purdue.edu/~pertierr/bluescreen1.tif

Since i only have two lights, the key object was lit with the same lights that are lighting the background, i just moved it towards the camera until it cast no shadow.

The only advice I can give is to make sure you separate your subject well with backlight, giving it a rim. Whe I don't do that, my Chroma Keys look terrible. Of course, you need to have that rim motivated by the background you're gong to replace the bluescreen with. I think you'll se a noticable difference.

to juan
 

<<<-- Originally posted by Juan P. Pertierra : ... Any suggestions from the chroma-keyers would be greatly appreciated.
-->>>


treat this as a starting point

http://www.ultimatte.com/

and you can find many *.pdfs about ultimatte solutions. you can download also demo from their site. probbably the best soft/hard ware i know now - sicnce ZBIg (rybczynski) enjoyed ultimatte and stopped his own product for cromakeying called zbig.

all the best

filip

p.s.

i cannot find really really good pdf from ultimatte (kind of " for dummies" series) which i downloaded some years ago with exellent explanations how, when and why to use chromakeying techniques. but if i find - will send it here.

p.s. 2

but maybe you should find ZBIG demo, it's available somewhere on the net. this is really amazing soft. demo will put some grid on your screen, but... if you need it for your tests - it works perfectly

Hey Juan don't worry about a shadow. I would just point one light at the subject and board at an angle and just leave a shadow on one side. Maybe with the other light you could point it at the ceiling or the oposite wall to bounce a small amount of light onto the dark side of the subject. Shhoting shadowless bluescreens are fine for fake or head only composite jobs but what about virtual environments? When actors stand on a bluescreen stage there are always shadows. This is just something a good keyer has to know to deal with. Besides we know this thing will work great with a perfect blue screen setup. Even DV can look good with a perfect setup. We should test setups with uneven lighting and harsh shadows.

that bluescreen looks pretty dark. Bring your subject and light closer to the screen to get a nice deep blue color. Don't worry about shadows.