Sorry guys but I get lost.
Too many questions to answer!!!! :D

BEN

I mean 4.5:1 only for Green.Don't know really.Maybe something became lossy in the way, which is a rather common bug when you're working with transformations,etc.Time will tell.....

OBIN

My usual workflow is as follow in such cases:
I convert everything to 8 bit.
I edit everything.
I export an EDL or AAF.
I open this EDL or AAF someplace with support for 16 bit.
I apply CC.

Ready :D

DAVID

So how do Huffyuv, XVID, and other YUV planar image formats to work with VFW?
About 10 or 16 bit I know nothing at this moment.
We were just thinking about going the usual way and use 6 bits from the alpha cannel to store them in the RGB or YUV 4:4:4 version.(Remember I'm not the coding expert)
You are the specialist :D :D

What do you mean by 'interchangeable' ?

So, you say we must use Directshow.....



Nobody answered my question about MXF yet.....

BTW: Speed Razor says it support Cineon 10 bit data.

<<<-- Originally posted by Juan M. M. Fiebelkorn :
So how do Huffyuv, XVID, and other YUV planar image formats to work with VFW?-->>>

VFW only supports RGB on decode, this I know for sure. Try decoding a HUFF using graphEdit and you will see the problem. However the encoder does support YUY2 input, I don't know what tricks if any they do for YUV support. It seems the only way to use HUFFYUV as a YUV decoder is create your own importer for a tools like AE and PPro.

VFW is an obsolete API due to it 8bit and RGB issues. DirectShow it much more flexible, and less obsolete.

<<<--What do you mean by 'interchangeable' ?-->>>

The problem with Bayer data is it look like 1280x720x8 or 16bit image to average encoder, yet it is not. So if you declare the Bayer data with a new FOURCC code, your encoder can know what to do. If codec agree on the FOURCC codes different codec can be exchanged as needed.

hmmm...SpeedRazor eh? is that a standalone package or a whole computer system with lots of hardware?

hmm 10bit...this sounds good...do you think that quicktime is supported in Razor ??

AFAIK is a software package.
Try Google :)


http://www.in-sync.com/products/product.php?ID=3E9DD01F

Don't know the rest.

Has anybody checked out Ben's plugin for AE??

Other than the zippered artifacts on some of the edges (Ben, I've emailed you about this, you might want to adjust your algorithm a little bit), this plug-in is very, very nice!

One bad side-effect of the zippering on the edges is that it makes them crawl as you're panning across an image and the edges pass across the screen.

But other than the zippering (and there are other algorithms out there that don't "zipper" as much), this is a very, very good plug-in

Hey Obin,

I'm beginning to wonder,

Is the horizontal "smearing" artifact we're seeing a result of the CMOS chip or your cheap lenses?

Since they're coming from bright areas in the image, and they're a bit diffuse and even taper off as you go towards the edges of the image, I'm thinking they might not be a results of the CMOS chip, but some interesting flare artifacts from the c-mount lenses you've been using.

I haven't tried Ben's filters directly but they appear to be linear interlopaters only. I have the origin Obin sequence that generated this image using Ben's filter shown here:

http://www.dv3productions.com/test_images/ben_test_on.jpg

Using the original source, here is the best de-bayer I could come up with so far. It is heavy processing (slow at 3fps on my 2.5GHz P4.)

http://www.cineform.com/downloads/CineForm_debayer.jpg

I still have a problem on the left edge, but I believe this is due to the why I extracted the source data not the bayer filter (as the right edge is perfect.) Overall I believe the image is sharper with more detail.

This image is zoomed in 400% to show the key areas of improvement.

http://www.cineform.com/downloads/BayerCompare.jpg

P.S. The slight color variation between examples is due to the gamma correction applied not the de-bayer algorithm.

Hi David,

That's a very nice interpolation you have going on there.

BTW, does this have to be bundled with Cineform, or can we also get a seperate plug-in like Ben's? I really like the way that Ben's plug-in can integrate into AE or Combustion (actually right now Ben's plug-in is crashing AE, but works in Combustion), and then I can add more filters on top of that.

Also do you think there's the possibility of getting that Bayer de-mosaic plug-in for the Mac version of AE?

BTW, there seems to be some "zippered" edges on the "O", the "N", etc. on the words "Natinonal Geographic". Also I'm noticing some heavy banding. Was this a result of just preliminary experiments? Are "zippering" artifacts something we're going to have to live with on edges? For some reason I never see "zippering" on my Canon D60 shots, even on fine edges when you zoom in on them, and that has to go through bayer-demosaicing too.

Jason and David,

Yeah, the current implementation of linBayer is, as the name suggests, purely linear. I do this for two reasons: it's fast, and it's lossless. By lossless I mean that the original values are maintained, so if you wanted to, you could take the RGB image and recover 100% of the original RAW data.

I'm also developing a higher-quality algorithm, probably based on splines.

I'll keep you posted!

Jason, the reason you never see zippering artifacts on your Canon is probably that Canon is doing some very aggressive de-bayering. I'm guessing they're losing a lot more softness than us...

- ben

Jason,

It certain could be broken out into a AE filter (PC yes, Mac unlikely unless we release code); right now it is a DirectShow filter. CineForm is still working ideas on how to productize this stuff.

There is a balance maintaining detail and smoothing out any possible aliasing, the area you point out would be likely be aliased even on a 3 chip camera. I choose the algorithm based various de-mosiacing papers then indicated that this was a good all senarios (different image types) approach. This uses median filtering on chroma differences -- it is the median filtering that makes it slow.

Why would the Mac version be unlikely unless you release code (do you mean open source it?)??

Or are you saying that right now you're basing off some libraries/frameworks that are not available on the Mac (Directshow), so unless you actually release this plug-in to the public, you're going to have to re-program it for the mac.

I see what you're saying about the aliasing. It'd be interesting to see it in motion.

Looks good overall though.

Ben,
In case you haven't seen this paper, take a look !
He covers many of the methods, and has code to try them out.
The code is for MATLAB but it's easy to see what it does.

I like the variable gradient method, but it's the slowest.
But what do we care, it's quality we want, and it's still faster than taking film to the lab !

He covers the computational cost on the methods as well, to help see what they take.

www-ise.stanford.edu/~tingchen/main.htm


-Les



<<<-- Originally posted by Ben Syverson : Jason and David,

Yeah, the current implementation of linBayer is, as the name suggests, purely linear. I do this for two reasons: it's fast, and it's lossless. By lossless I mean that the original values are maintained, so if you wanted to, you could take the RGB image and recover 100% of the original RAW data.

I'm also developing a higher-quality algorithm, probably based on splines.

I'll keep you posted!

- ben -->>>

<<<-- Originally posted by Jason Rodriguez : Why would the Mac version be unlikely unless you release code (do you mean open source it?)?? -->>>

We don't have any Macs or a development enviroment for a Mac. At least for today all CineForm tools will be PC based.

Question for Obin, Steve:

Based on some new bayer interpolation stuff that's recently become available, how much would it cost to buy the equipment for shooting a short film with this stuff?

I'm assuming you'd need the SI-1300

A PC to attach to with card and capture software,

Hard-drives (of course :-)

Software for editing, color-correction (I already have that).

A lens.

Can XCAP be used on a short film? Do you need Stream-pix as well to get a RAW bayer image (no interpolation, just a black-and-white checker patterned image)? Do you also have to mount the camera inside another camera like you did Obin?

And lastly,

Have the rolling shutter artifacts been "solved"??

Do we even have sound-sync?

I'm really starting to entertain the notion of shooting a short film with one of these cameras. I've got the script, and I'm ready to go if the problems have been sorted out with the logistics of the camera (rolling shutter, and that weird vertical smearing I've seen in some of Obin's stuff). Altough depending on pricing, I may want to see what's coming around the corner (even Kinetta stuff-but that would be through rental).

Hey Obin, could you check an make sure it's not the lens making those smearing patterns?

I guess I'll think about it now, and see what happens when the Altasens stuff hits the market.

BTW, Mini-ITX isn't going to work for this stuff, is it?

Thanks Les!

I've read the paper, but I'm going a different route. I'm developing a logic-based (as opposed to mathematic) de-zippering routine. I'll posts some results in the next hour or so.

- ben

actually it seems this post is gone on another topic (compression and software) but i just take a look on the imperx web site and they get a nice chip and a pcmcia camera link card that could help to build a very compact/low power design.

Giroud,

I looked with great interest at the Imperx products, but once I got the quote sheet, my interest waned. Their cameras start at $4600 for anything over 1004x1004 in color... In contrast, I'm putting my entire rig together for about $2500, including camera, laptop, high speed HD and a brand new high resolution lens from Edmunds Optical. Of course, it remains to be seen if it will actually all work. :)

- ben

Found a new Pentium M-based embedded product coming to market soon.

http://www.kontron.com/products/pdproductdetail.cfm?keyProduct=40088&kps=1082&kp=75

This one will have 64-bit PCI-X slots through a special riser card. Also has dual SATA interface and an IDE interface for a boot drive.

Jason on smearing:
That smearing with oversaturated pixels is a Micron problem (all Micron 1.3Mpix cameras will have it). Definitely not the lenses. I bugged them about it and they said run slower, which negates what we want to do about rolling shutter. I was told (but haven't seen) that the 3.2Mpix Micron doesn't do that as much - different pixel architecture. The 3.2Mpix should be able to do both 720p and 1920x1080@24fps, 10 bit. If Obin and Rob want to upgrade in about a month I'll work it out with them. The SI-3300 will have less sensitivity though.

Jason on recording:
To do what you want to do as a minimalist, you can use our standard camera, c mount lens, direct-to-disk recording software (streampix will beat xcap for this) and then your own processing chain. Rob or Obin might have the recording thing done, but maybe not in time for you.

Giroud and Ben on Imperx:
They have the only Cardbus cameralink frame grabber that I know of. If there is a request, I can get them to qualify our cameras (maybe the SI-3300 first) on it but you are at the mercy of their software support. This is the joy of an industry standard. They can use our cameras.

Does the Altasens have verticle pixel smearing?

jason I am working on design for a standalone camera very "Kinetta" like but simple and easy to use ...do you have any idea what that new microboard chipset is? i need hardware that will run with Linux for the UI of this stand-alone Rig ;)

I jsut looked at that board page looks like, 855GME, 6300ESB(Hance Rapids) chipsets

anyone know if that is a standard chipset? or?

I think that may be the Perfect Board for a camera!!

My brother is a CAD/FX guy.. I will start working out the system design soon...fun fun fun!

Hey,

The new version of linBayer is done for now. I'll come back to it a bit later. Here's a comparison.

Old linBayer image (http://www.bensyverson.com/pictures/linbayer/oldlinbayer.jpg)

New linBayer algorithm (http://www.bensyverson.com/pictures/linbayer/linbayernormal.jpg)

New linBayer algorithm (aggressive de-zippering) (http://www.bensyverson.com/pictures/linbayer/linbayeraggressive.jpg)

The aggressive de-zippering option is great for random fine detail like text, but it can introduce stray pixel artifacts on strong, fine horizontal and vertical lines. For those images, leaving aggressive de-zippering off will be the best compromise.

Best of all, there is no computationally intensive math. It's just about exactly as fast as linear interpolation. Also, the process is still lossless. All of the original pixel values are untouched, which means you'll be able to re-do the de-bayer process later if a better algorithm comes along.

I've posted the new build of the mac version to the linBayer website. The PC version will follow a bit later. Right now I have to go to the lake and play scrabble.

- ben

According to the info page:

Up to 2.4GHz Pentium M processors using Intel 855GME, 6300ESB(Hance Rapids) chipsets

BTW Obin, are you still going to be useing the Microns? Right now it seems as though that veritcal smear problem is a real show-stopper since it really limits your dynamic range. Steve, I know you said that the newer chips is going to have "less" of this problem, but if it's still a problem nonetheless, hmm, then I guess the Altasens will be worth waiting around for. I mean I think it would be silly to pay $3000 for a camera and then have a major artifact to deal with.

One more thing though, is this problem ONLY when you oversaturate the chip, or just when you have a bright area?

BTW Obin,

remember that there's a riser card needed for the 64-bit PCI-X slot, so that's extra space that you don't see on that board. I'm assuming that the card will fit over the top (so you'll have to find a place to mount the hard-drives somewhere else).

Another thing Obin, check out Ben's plug-in when he gets the PC version up. The new version is very good, you'll be straining your eyes to see any artifacting. And the nice thing is it works now, not five months or a year from now :-)

P.S. that wasn't mean to be a jab at anyone, just saying this a great solution for getting up and going right away.

Obin, do you have an JVC HD-10 you can use for tests ?
-Les

the AWESOME thing about that board is it's got sata AND pci-x !! we can get 4 sata drives and a pci-x grabber and the datarates would be HUGE! I bet 60fps from the 1080p chip at 10bit ;0 ?? can raid the 4 sata disks OR have the software write frame 1 -> disk 1 frame 2 disk2 etc

as far as I can tell Jason the chip only does that smear when you hit 255 white or above..I could be wrong..for me I feel we can shoot around that issue and the resolution and bit depth far outweigh the problem. It is an issue nonetheless.

I do not have the jvc hdcamera

If it's only when you hit 255, then I think you're fine, but if it's simply brighter areas, then that's a problem, because the hot stripes ruin your dynamic range-you can't lift up the blacks or else you get these nice light stripes running through the image. Not good.

This might be something you want to check into further.

when will we have pci E frame grabbers Steve? that is a VERY fast standard Shuttle has a new board that has one pci E slot..news??

Obin and Steve,
So If I add a mechanical shutter at 1/48th to the sensor and run it at 24 fps (not 48 to avoid rolling shutter) I won't have the smearing problem?
I ask cause, if this solution gives better quality I'd go this way.

If someone is interested DCRAW uses the Variable Gradients Method.

Variable Gradients is an interesting approach, but from what I understand, it's fairly slow.

My algorithm could probably work in a realtime pipeline if you optimized it. Processors with SIMD (single instruction multiple data) such as the G4/G5 and the newer Pentiums should have no problem with it. Also, I think it could be put onto a FPGA pretty easily if that ever becomes a reality...

Hey, I posted the PC version of my updated linBayer plugin here (http://www.bensyverson.com/software/plugins/linbayer/) for you guys to check out. Jason + I have been working on getting all the kinks out, and I think it's to a pretty good point. I was able to eliminate some artifacting in noisy areas in this latest build.

David wrote:
We don't have any Macs or a development enviroment for a Mac. At least for today all CineForm tools will be PC based.

Sounds like you're missing out on a massive chunk of the market (if you're at all interested in this market). Mac users probably make up the majority of people interested in low-cost HD solutions for filmmaking.

Just a thought. $10k investment for a possibly massive return...

Might be the opposite.
People willing to play with non standard and somewhat self made hacked together hardware are more likely PC people.
Ever been to a Computer swap (fair) ?
Here in LA it's like two football fields of vendors with all shapes and forms. No Macs, except a couple of old junk ones in a used pile for $5.

Maybe people who hate being locked into a single source for the computer also eschew the big name video vendors, like Sony and Matsushita.
I like open hardware, myself.

That's okay, we Mac users replace not having open hardware with open software ;-)

I do think it's pretty cool that since OSX/Darwin has hit the market, I've been able to play around with all the goodies of the OSS market while still enjoying "mainstream" apps like Adobe, FCP, etc.

I'm sure you can do a lot of similar stuff with cygwin, but I've found many GTK-based stuff, or anything that wants X-windows to be pretty buggy on Windows versus a native X interface like I can get in OSX (special install).

Also Ben, I bet if you wrote that linBayer as a CoreImage/CoreVideo plug-in, you'd be seeing real-time results. Of course that won't be released till "Tiger" comes out, but I've seen it do real-time gaussian blurs, etc., and those filters take a lot longer to process on my machine (dual 2Ghz G5) than your linBayer filter does in AE-so I'm assuming that it's less processor intensive than a heavy gaussian, and if that plays back RT in CoreImage/Video, then your filter should be a real-time conversion as well.

P.S. BTW, I'm not trying to make this a Mac/PC war, I realize that right now I'll have to purchase a PC anyways if I'm gonna have one of these industrial cameras.

OMG CoreVideo looks HOT!!! I hope someone does this for windows soon...we are all using $100 agp cards that could do EVERYTHING in realtime even HD ..yet not a program uses them but games...shame...it would be Apple that changes that ;) and I am a windows person

Les wrote:
People willing to play with non standard and somewhat self made hacked together hardware are more likely PC people.

Yes, most definitely. I'm talking directly to the vendors: if you wanted to, you could develop an HD system that didn't need to be "hacked together," one that could be a much more mainstream solution. Think of all the FCP jockeys out there begging for a better format than DV or HDV. The filmmaking market is at least as big as the scientific market -- trust me. And a lot of those people are Mac users.

I can name 10-20 people off the top of my head who would put down a deposit right now if you could deliver them a camera that pushed HD footage at 24fps through USB2, Firewire or Firewire800. You could sell such a camera for $3000 or $4000 (with $1000 - $2000 worth of parts) that would appeal to thousands of videographers, filmmakers and others for whom HDV is not going to cut it. But CameraLink will not sell units to this crowd, except a few dedicated individuals like Obin.

This whole thing is set to explode in the next 18 months, and whoever is out there first stands to gain the most ground. Here's what you need: a 720p camera that can deliver at least 24fps over one (ideally a couple) of the interfaces I mentioned at 8 or 10bit. 12bit is overkill for the most users. 10bit 720p at 24fps is around 26MB/sec, which most 7200rpm drives can keep up with. Maybe do some compression via a FPGA in the camera to get it down to 18 or 20MB/sec -- by the time you have a shippable product (12 months?), you'll have no trouble approving laptops to handle it.

Software vendors are screwed -- this market won't like kludgy proprietary tools. We'll build our own or buy better integrated tools.

In the next 18-24 months the "industrial" camera websites we all visit will cater to both the scientific and filmmaking communities. Some may only cater to the film community (since it's potentially far more profitable).

Be there first.

- ben

I was here first ;)

looks like windows xp embedded is a good os for the camera

Obin: We all give you props for being our Chuck Yeager. :)

Jason + I ran into an interesting problem today. He noticed a "gridlike" effect in the de-bayered results of my filter, when I knew there was no reason for that effect to occur normally. I looked into it, and we found that the green pixels in odd rows were often globally different than the green pixels in even rows. When I analyzed the pixels, I found that the green pixels in a blue row might be (in 8bit):
100, 98, 99, 97, 96, 98
but on the next row, a red row, the green pixels might be:
92, 90, 90, 89, 85, 88

Steve, have you seen this before?

The rows were sometimes off by as much as 10 or 12 values, which is a significant deviation. The only logical explanation for this is that the physical bayer filter grid on the sensor is veeeeeeeeery slightly mis-registered. Like it's a little up or down of where it should be. As a result, the blue and red filter areas are covering up the green sensors a little bit, and since blue blocks more light than red, you get a value difference. The red+blue channels come out even because they're being corrupted equally by only the green filters. But the greater the registration error, the lower the accuracy of the color. I verified this hypothesis by analyzing pixels from areas where the R & B are very different, and where they're almost the same -- sure enough, the greater the contrast between R&B, the more "interlacing" artifacts in the G.

This isn't Micron-specific, I've seen this on images from the IBIS5 sensor as well. It must be a manufacturing nightmare to register a filter on a 2/3" megapixel + sensor, when your margin of error is around 1 micron -- 1/25400th of an inch! So guys, this is yet another reason to buy sensors with bigger pixels -- not only does their light sensitivity go up, but the bayer registration is almost certainly better. If you have 12 micron pixels as opposed to 6, an error of 1 micron won't be so dramatic.

I'll build a slider into linBayer to counteract this effect on the green channel, but using it will necessarily affect the original values of the image, and thus the process will not be totally lossless.

- ben

More cameras:

http://www.mikrotron.de/en_cameras_mikrotron.shtml#mc1301

After playing with more of the Micron images, the bayer registration seems to be pretty solid. It's the IBIS-5 images that need more help.

I posted the updated version with registration correction, and more control over the de-zippering process.

Ben on zippers:
The Micron has 4 analog gain amps - R, G1, G2, B. This means odd and even rows have their own gain setting. Either they are set differently or they are not balanced in the original image. For Obin, I would suggest live viewing and zoom way up on a solid color image. That is how we balance columns on the IBIS5.

I haven't heard a FG manufacturer talk about PCI-E. PC-104+, yes.

Ben on Bayer:
I think you hit something very significant when you said that the original pixels are not modified so you can go back at any time and re-do the Bayer. I hadn't thought of that before. It means that if you find an incredibly complex algorithm, you could run it on the final cut of the film if you stay had high bit depths through editing.

Smearing:
In about 1.5 weeks I'll let you know about the SI-3300 smear - micron says it should be much better. I haven't heard of the Altasens smearing any which way.

Steve:

I don't see how we can use the 3300 at all as your going to window the chip for 1280x720 and even for 1080p..it's a 1/2 inch chip as-is so making that chip work with a decent FOV...I don't see how unless you can do some type of superpixels/binning ?? OR and this is the BEST if you could resize the native image BEFORE it is saved with a realtime dsp/fpga chip?? if you could resize it would make that chip BETTER then the Altasens chip because it will be MUCH sharper @ the resolution of 1080p or 720p because it's been downsized..this would be VERY good...

If that could be done I would take the 3300 over the Altasens

About SI 3300,

Isn't it a 1920x1080 capable Sensor??
Am I missing something?

edit:Oh, sorry.I went to SI's page And I read it is a 2048x1536 chip but at 15 fps.
Does SI have a chip capable of 1920x1080 or higher at 24 fps or higher.
BTW the page is a little messed up.

About frame grabbers.
Manufacturers are not working with PCI-E at this moment cause PCI-X 64 bits 133 MHZ is still the fastest interface availabe (under the PCI standard) and will be for the next year.
Athough PCI-E specifications allow for bigger transfers, they are not planned to be implemented in the near future except for GPU.

Steve et al,

The Eden processors themselves don't do RAID, but motherboards like the mini-itx designs at http://www.mini-itx.com definitely support PCI cards which you can do RAID through. Check out this project on mini-itx.com (http://www.mini-itx.com/projects/tuxserver/) -- a guy created a RAID of notebook drives and hooked them up to his mini-itx via a PCI ATA controller. Odds are you'll be able to do the same thing with the coming Nano-Itx boards.

Of course, then the problem becomes how to deliver enough power to the board and the drives. I don't know the figures offhand, but while these boards draw way less power than a typical desktop, I think they draw more than most laptops. Then your problem becomes finding a DC-DC converter to regulate the current, and finding a battery that can feed it. Oh, and what are you going to use for an LCD monitor?

The whole setup is likely to be to be pretty large. Like one of those ENG (news) video cameras.

On the other hand, laptops keep getting faster and adding more features. And they have the whole power/battery/LCD issue solved. What we need are Firewire a/b or Gigabit Ethernet cameras.

- ben

Ben,
Maybe we should pay attention to the tablet PCs. Is there a very small one? Losing the keyboard entirely and gaining a touchscreen is probably the best way to go. I can't imagine an easy to use camera attached to a full laptop. There are some really nice LCD panels for around $400-$600 w/ full VGA or better displays. The RS-170 panels are way down in price but other than framing a shot they would be pretty useless.

I think a key point is the real-time compression. If you don't do it, you probably need a RAID for anything over25MB/sec with a standard drive and about 45MB/sec with a SATA drive. If you put in the processing power for RT compression, you can write to a small drive but probably dropped 100W of power to get there.

The smallest tablet is the Sony VAIO U70 (http://www.dynamism.com/u70/). But the micro HD inside will never keep up with the data.

These small screens can be had at 800x600 or even 1024x768 res. I have an older Sony U3 (http://www.dynamism.com/u3/) and its 6.4" screen is 1024x768...

The biggest problem with small solutions is that they don't have 2.5" drives in them, so you can't ramp up to 7200rpm. You need a full notebook/tablet for that. In my book, a tablet is every bit as cumbersome as a notebook, perhaps more so. At least you can put a laptop on a surface and read its screen -- a tablet will lie flat, forcing you to stand directly over it or pick it up.

If you want internal RAID, you are essentially fscked when it comes to notebooks. However, I've been thinking lately that it should be possible to daisy chain a few 2.5" Firewire drives together and do software RAID. Since these drives are powered over the FW bus, you wouldn't need to plug them in. Each FW bus is supposed to deliver 45w, but even if it's less, it's probably enough to drive four 2.5" drives.

The trick would be figuring out the power/speed tradeoff. If you have enough power, you could do 4 7200rpm drives. If you aren't getting much power, you could swap them out for 4200rpm drives...

- ben

I think it's totally feasible to do realtime compression. Here's how it would work for a 1280x720 image.

1. Read in the bayer image off the camera.
2. March through the pixels, separating the image into 3 channels -- R & B at 640x360, and G at 640x720.
3. Compress each channel losslessly.
4. Throw that data into a file.

In reality, steps 2 + 3 would be happening at the same time.

If you're shooting 1280x720 at 24fps at 10bit, you're only using 26.3MB/sec. You might not need compression or RAID to keep up with this if the Hitachi 7200rpm drive is fast enough. But if we assume we can get at least 1.5:1 compression on each channel, that drops us to 17.5MB/sec.

We can definitely handle that. Lossless compression is very fast -- if you built it into the frame-writing code, it wouldn't take too much longer that writing an uncompressed frame.

- ben

Steve do you have a reply for the above?

does anyone know if recording to ram is a good idea? this would allow a laptop to be an all in one capture device?

Eric,

I think it's a great idea, if you can handle the limitations. The max ram a laptop can hold is 2gb. You'll want at least 256-512 allocated as "real" ram, and then you can make the rest into a RAM disk. That leaves you with about 1536mb. Recording at 26.3mb/sec (1280x720 @ 24fps, 10bit), you'll have just under a minute of shooting time. Then you'll have a delay as it writes out to disk.

A better idea might be a portable RAID. I suggested this in another thread earlier today, and I've since done a bit more research. The basic idea is to strap three or four 2.5" external Firewire hard drives together and daisy chain them. Because laptop drives can be powered from the FW bus, it could be totally portable.

2.5" laptop hard drives draw a maximum of 5 watts during start up (5.5 in the case of the Hitachi 7200rpm drive) and around 2.5 - 2.7 watts during use. The Firewire bus should be able to supply a maximum of 45 watts -- I don't know if you get less on laptops. Regardless, if you use three drives, your maximum power draw during operation will be around 8-9 watts. Hopefully the Firewire bus on laptops would provide you with that much.

Even a 4200rpm drive can write at about 10MB/sec in the worst-case scenario (random drive locations), and around 20MB/sec in the best-case (sequential drive locations). With software-based RAID 0 for 3 drives, I don't think there would be any problem reaching 30MB/sec. Burst rates (which are improved the most by RAID 0) would probably be faster than the bus could handle (50MB/sec), unless you were working with FW800 enclosures.

Steve, what do you think of all this?

- ben

Ben and Steve,

The Eden processor consumes less than a laptop.
If you don't believe me go check the specs of Eden and Pentium M or Athlon Mobile.
About the compression system you are right, that's the way!!
(I've been saying that since I entered this board, and now I'm trying to develop a solution for that.)
Be aware that for every normal drive you add tho the system you add around 15 watts to your power requirements, so keeping one drive and going compression is a more power friendly solution.
About displays, there are many 7 inches Touchscreen LCD displays with VGA connector, with a resolution of 1024x768 for around $300.Mini-ITX website

My Maxtor Disk, 7200 rpm says: aound 900 miliampers for 12v and 630 milliampers for 5v.



Explanation of huffyuv internals

http://home.pcisys.net/~melanson/codecs/huffyuv.txt

By the way, I just got a Mac G5 with OSX and FCP HD . . . you bet your butt I'd buy that camera!!!!!!

Explanation of Huffyuv internals

http://home.pcisys.net/~melanson/codecs/huffyuv.txt

I jsut bought a 8in touch-screen I will keep you posted when it arrives!