Using WP with Macintosh

[blackfrog]

Hey Roger and DigVid

Interesting that you guys ran a frame-differencing scheme at up to 12 fps. That's the theoretical limit of my algorithm also, but by capturing at 6 fps, I am confident that I have a one-to-one transfer with no images that are slightly blurred (at the beginning or end of film motion).

I started out writing synchronized capture software, but insuring a one-to-one transfer was my number one priority, not transfer/processing time. Also, this post-processing tool was much easier to write ;-)

I agree that this scheme requires a lot of disk space. But since I'm also working with a lot of mini DV video, I've upped my laptop hard drive to 80GB, and I have two scratch firewire drives of 30GB and 40GB each. I capture several movies in one setting, then batch process at night. I haven't measured the actual throughput of these drives (Ultra ATA 100 on Firewire), but iMovie transfers DV video at 30fps in realtime, so I don't need a RAID system. This is true of the lowliest iMac/eMac with a Firewire interface.

I've also thought about spending some time optimizing my tool to run in real-time, and processing the images live. I'm currently processing at 5 fps, so I'd need a 6x speedup, but I know some things I can improve. This would save one step, but I would still be running at 6fps (or theoretically up to 12 fps).

My son is 8 months old. It is incredible to film him, then rip super8 films of myself at his age (and my parents at my age). This workprinter is a fantastically cool toy. I even found an old 8mm film from my Uncle's camera, which contained the last images of him before he left for Viet Nam, where he was killed. You can imagine the emotional value of that piece of film.

Well, unless someone else is interested, I'll probably leave my tool as is. I'm currently pouring a lot of time into a startup company, playing with my son, and making movies and DVD's. Time is what I'm lacking. If I do make any more software improvements, I'll post them here.

Cheers, guys.

p.s. it's nice to see a WorkPrinter forum online!

[STREDGE]

It works fine and my mac isnt even one of the faster ones. I use the mac software everyone has mentioned. My computer is a dual processor G4 450mhz. I have 640 megs of ram and no raid drives. I have had no capturing problems
andy

[supa_ate_sixteen]

andy I think the issue is more related to the speed at which one can capture on the mac rather than just the ability to make it work. If the new G5's running jaguar OS 10.2 or 3 can't capture at 6 fps I would be amazed. Theyre supposed to be the "worlds" fastest personal computer.

[mattias]

If the new G5's running jaguar OS 10.2 or 3 can't capture at 6 fps I would be amazed. Theyre supposed to be the "worlds" fastest personal computer.

even the old imacs are fast enough -- this is a software problem. the problem with most stop motion capture applications on the mac is that they capture the decompressed data and recompress it rather than just saving the compressed frames to disk. there nothing about the hardware design or operating system that's the cause of this, just the ignorance/laziness or whatever of the programmers. ;-)

/matt

[Skylab001]

I'm using a MAC with my WP jr. using a G4 350mhz....yes a slow dog....I would recommend say a 450+mhz and a single 7200rpm drive and it should work great. Capturemate is the program I'm using to capture with and it is very efficient. I am transferring Uncompressed 8bit YUV video, but if you are using standard Mini DV you should be fine with almost any G4. Oh yeah I'm also running OSX.2 Jaguar which helps to speed things up as well....

[MovieStuff]

Well, again, the thing to remember is that is not about throughput as much as it is about how fast a given Mac or PC can process mouse commands. The ability for a computer to capture streaming video at 30fps has little relevance to whether it can process 6-8 mouse commands a second without falling behind. Before CaptureMate, Macs using Premier would fall behind after about 8 mouse clicks. You could stop at frame 20 and watch the capture numbers continue - 9, 10, 11, 12, 13, etc. very slowly. The Mac wouldn't drop any commands but would fall out of synch with the pulldown of the WorkPrinter. CaptureMate solved that problem but I still recommend a Raid for optimum and consistent performance.

Roger

[digvid]

Blackfrog -

>
> Interesting that you guys ran a frame-differencing scheme at up to
> 12 fps. That's the theoretical limit of my algorithm also, but by
> capturing at 6 fps, I am confident that I have a one-to-one transfer
> with no images that are slightly blurred (at the beginning or end of
> film motion).
>

"Theoretical limit" eh? You sound like my kind of programmer! That is actually what I enjoyed most about working on this kind of program. There was a lot of theory involved in terms of figuring out how fast you could possibly run, etc. It is a very challenging problem from a programming standpoint.

About getting a one-to-one transfer: does your algorithm take into account varying content of the frames? For instance, what if you have a lengthy run of frames that are very nearly black, or that are identical? Also, do you always run with 1/60 shutter speed? I found that at faster shutter speeds you can actually miss recording the "blur" in between frames. I had to build smarts into my algorithm that guesstimated where frame divisions should be if the frame differentiation algorithm failed to detect it.

>
> My son is 8 months old. It is incredible to film him, then rip super8 films
> of myself at his age (and my parents at my age).
>

Ah! I have a little one too, although he is a little older than yours (about 22 months). I keep meaning to make some Super8 films of him. Video is great, but I really value having old footage of myself and my family, and I think it would be great to have film footage of him as well. Hopefully later in life he will appreciate it. If he doesn't, I'll disinherit him (just kidding).

With a family and little tyke, it is sometimes very hard finding time to program. About a year ago, I fell down some steps (guess I'm not as young as I used to be...) and snapped my Achilles tendon like a dry twig. This put me out of commission for a number of months, which gave me lots of free time to think and program. It was during this time that I put out the last major release of my software. It was nice having the time to program something big, but I can't say that I recommend my method.

>
>Well, unless someone else is interested, I'll probably leave my tool as
> is. I'm currently pouring a lot of time into a startup company, playing
> with my son, and making movies and DVD's. Time is what I'm lacking.
> If I do make any more software improvements, I'll post them here.
>

I'm sure someone will be interested. Also, as hard drive space becomes cheaper and cheaper, that aspect of it will be less of an issue. The main benefit I see is that it might make it more feasible to do capture with portable systems (i.e., on a laptop). Anyway, it is a really fun problem to work on if you have the time. Keep us updated on your progress if you continue to work on it!

[STREDGE]

andy I think the issue is more related to the speed at which one can capture on the mac rather than just the ability to make it work. If the new G5's running jaguar OS 10.2 or 3 can't capture at 6 fps I would be amazed. Theyre supposed to be the "worlds" fastest personal computer.

i have a workprinter xp so i only capture at 6fps
andy

[mattias]

hey guys, why don't you just record the time code for each mouse click while feeding the full stream to disk and use that to extract the right frames later? this would require the camera to be generating tc of course, but you might not need "real" tc. how about recording frame numbers or simply the time? you can calculate tc from that pretty easily even if you're using drop frame.

/matt

[digvid]

At 6 fps, recording timecode of the mouseclicks will work, but only if the WorkPrinter is synched. Much faster than that and it won't work at all. Using frame differentiation, however, you never have to worry about synching the WP!

If you only rely on mouseclick timecode, you immediately lose all advantages of doing the streaming method versus stop-motion capture.

- digvid

[blackfrog]

Hi Digvid,

>does your algorithm take into account
>varying content of the frames?
>For instance, what if you have a
>lengthy run of frames that are very
>nearly black, or that are identical?

Yes, I have to distinguish between nearly identical frames, camera noise, etc., by counting frames. For example, if my projector is running at 6fps, let's say the camera grabs the following 15 frames (# is the film frame number, and b is a blurred frame):

11111b222233333

I frame difference these frames with a fixed tolerance, and get the following (d is a difference frame, s is a similar frame, and the first frame is always a d frame):

dssssddsssdssss

It's easy to pick out the frame boundaries. I look for the first pair of similar frames, keep one, then skip the remainder of similar frames until I find a diff frame, then look for another pair of similar frames. In this example, I would keep frames 1, 7, and 11.

I use a fixed tolerance when frame differencing. Too small of a tolerance can make camera noise look like a different frame, resulting in this situation:

dsddsddsdssdssds

In that case it's much harder to pick the frame boundaries. Instead, I use a fairly liberal tolerance, but I do need to distinguish similar frames, which I do by counting. For example, if film frames 2 and 3 are similar, the frame differencing might look like this:

dssssddssssssss

By counting the number of expected similar frames, I can tell when I encounter this situation. I expect 3 or 4 similar frames, not nine in a row, so I pull the third frame 6 frames after that last known frame, resulting in the following keepers: 1, 7, and 13.

On very long runs of similar frames, I end up blindly selecting every 6th frame, which could end up with some dupes. But I take comfort that if the frames look similar to my algorithm, they'll look similar to the naked eye. In reality, there are not many long runs (none more than 22 frames), and I analyzed some of these and found that the scheme worked.

>Also, do you always run with 1/60
>shutter speed? I found that at faster
>shutter speeds you can actually miss
>recording the "blur" in between frames.
>I had to build smarts into my algorithm
>that guesstimated where frame divisions
>should be if the frame differentiation
>algorithm failed to detect it.

I'm using a Sony DCR-TRV22 miniDV camcorder. I'll have to see if I can control the shutter speed.

It sounds like you had to solve the same problem I did re the blur.

Ultimately, I'd like to tie the microswitch on the workprinter to the DTS line of the serial port, and use that to drive a synch-frame capture algorithm. I'd expect to get 18fps with that scheme, since the mac can reliably transfer 30fps on the firewire bus all day long. But hey, that's another project for another time.

I just can't say enough good things about this work printer. Since I first saw digital video in 1991, I've known that I wanted to digitally archive my parents' super8 movies. 12 years later, the WP and a DVD burner make this it's within reach. Now, if I can just get everything ripped and burned by Christmas...

cheers!

[digvid]

> Ultimately, I'd like to tie the microswitch on the workprinter to the DTS
> line of the serial port, and use that to drive a synch-frame capture
> algorithm. I'd expect to get 18fps with that scheme, since the mac can
> reliably transfer 30fps on the firewire bus all day long. But hey, that's
> another project for another time.

I think you'll find that it is impossible (under any circumstances) to get a capture at 18 fps whose visual quality matches what stop-motion does at 8 fps or so. The serial option I have also tried, and that definitely won't help you get 18 fps. The serial connection does have some advantages though. I actually use a serial connection with Dodcap for my stop-motion capture and it performs slightly better than the mouse. Good luck if you try it though!

- digvid

[mattias]

If you only rely on mouseclick timecode, you immediately lose all advantages of doing the streaming method versus stop-motion capture.

*all* adavantages? i think i see what you're saying, but i thought the issue in this thread was that the stop motion capture programs on the mac couldn't capture fast enough, so my point is they should in any case be able to record timecode fast enough which would be a quite simple solution to the problem. i think i could write a program to capture dv to disk while recording the frame numbers of the mouse clicks in about half an hour, if somebody is willing to write the software to extract the right frames.

/matt

[MovieStuff]

i thought the issue in this thread was that the stop motion capture programs on the mac couldn't capture fast enough, so my point is they should in any case be able to record timecode fast enough which would be a quite simple solution to the problem.

In theory, that is true. But, as you pointed out, not all camcorders output actual time code so something like time stamps *seemed* like a viable solution to us, as well. In fact, we experimented with recording time stamps during the digitizing process but found that mouse generated time stamps were subject to minute inaccuracies that made recording at 12fps no more viable than doing it "on demand". At 6fps, the time stamps seemed to work okay but, then again, so does capturing "on demand" via stop motion, so using timestamps offered no real increase in performance, which was our actual goal for PC users, which make up 99.99% of WorkPrinter-XP clients. Ultimately, whether using a PC or a MAC, setting up a Raid-0 is a minor consideration considering that it will provide the ability to record rapid stop motion "on demand" and will work (on PCs, anyway) up to 8.5fps and about 6fps reliably on MACs.

Also, the other reason that most people aren't using MACs for their captures with the WorkPrinter-XP units is that using a MAC, or ANY high end editing platform, makes little sense in a business environment, which is where the majority of these units are employed. Doing daily telecine transfers takes up a LOT of time and, as most customers have found, it makes zero sense tying up a revenue producing edit suite doing slave labor when PCs are so cheap. All you need is a basic PC shell with some matched drives and an el cheapo firewire board. MAC users with OSX can even network the capture PC to their edit system to suck the captured files right off the drive and can use the capture PC to render out the speed changes using DodCap, thereby not tying up their edit MAC or PC platform.

So, in all, there a variety of reasons that we've stuck with the "on demand" method of rapid stop motion capture. It's fast enough and has proven itself a dependable an efficient way of capturing for the majority of users that don't mind getting a Raid-0 for their capture system.

Roger

[mattias]

time stamps *seemed* like a viable solution to us, as well. In fact, we experimented with recording time stamps during the digitizing process but found that mouse generated time stamps were subject to minute inaccuracies that made recording at 12fps no more viable than doing it "on demand".

well again i'd like to point out that the subject of this thread is using a wp with a mac, and all i'm trying to do is suggest a solution to that problem. i've never said that recording frame numbers would in any way be better than a working on demand capturing.

/matt