Note: By specifying a "key" frame at the beginning of each part's handling you can modularize the data. This means that a whole key frame is stored and then just differences for each successive frame. This is what leads the the better compression of video such as MPEG4.
But note, you want almost continuous video at a 2 sec frame rate rather than 30 Hz. This slow down means that a DVD that holds 1 hour of video could hold about 60 times as much (2.5 days). You can gain something by decreasing the quality of the video, subtracting static backgrounds, etc. but there is a fundamental limit of how much data you want to keep! -Scott At 9:10 -0500 6/8/04, David Ferster wrote: >Check out Christophe Salzmann's QuickTime toolbox. It gives easy access to the >QuickTime compression codecs (MPEG 4 is especially good). Depending on how much >detail there is, you can compress 10-fold or more without much loss, and at your >frame rates you can do this on the fly, and never store the original images. > > >>A customer of mine has a process which takes about 40 seconds and operates on parts >>being manufactured. 15 seconds to get the part into position, 10 seconds to operate >>on it and 15 seconds to return the part. >> >>He wants to have color pictures taken for surveillance only - just to see if the >>part was mishandled and such. That is, there's absolutely no requirement for any >>kind of image analysis. >> >>He initially thought to use a PCI-1411 card with a standard video camera (PAL in our >>case) and snap pictures (2 every second while the part is in transport and 4 per >>second during the process). >> >>This results in LOTS of pictures which requires LOTS of disk space and archiving to >>DVD (about 2 days of pictures and data per DVD). They do about 10,000 parts each >>month. >> >>My question is: does anyone have a better idea? >> >>Just thought I'd throw this out to the multitude of brilliant (not to mention >>creative) people on this list to see if we've missed something. >> >>One more thing: the pictures would only be displayed off-line together with a part's >>data whenever the user wants. I suspect that each picture would have to be >>compressed (JPEG?) to conserve space.
