My little DIY camera project

[Noah Yuan-Vogel]

youre saying to basically write a macro to control their standard application? that might work, but it also would probably be no more difficult from starting from scratch. their standard application basically just uses all their api functions in their simplest forms giving them form buttons and sliders and whatnot. and just attaching some kind of macro wouldnt solve the problem of the application's capture limitations. the only advantage i see is in some of the features of their app that arent directly out of the api, like the framerate counter.

[Wayne Morellini]

Noah,

Writing new API, is starting from scratch and is very difficult. The real disadvantage you mentioned, was not being able to output an grey scale avi (I assume such a mode exists) instead of the RGB one.

As I understood from your description, the problem (apart from API capture) was that the interface was presented the wrong way without external non mouse controls. Can you explain the things that an new interface program will not solve?

[John Wyatt]

Noah, I would like to experiment with a M73 myself, though probably (to start with) working within the limitation of recording to RAM. I have 2 Gb of RAM in my desktop, and I understand 2 Gb is the maximum a laptop can be upgraded to. 2 Gb of RAM makes the scheme viable - well, for me anyway:

2 Gb of RAM split up for 0.5 Gb computer RAM, 1.5 Gb for "RAM disk".
USB 2.0 = approx 50 MBps.
1280 x 720 x 24 fps at 10-bit Bayer = approx 27 MBps.
27 MBps into 1.5 Gb RAM = approx 55 seconds.

Therefore, if these figures are right, 1280 x 720 x 24 fps at 10-bit could be recorded for around 50 seconds per shot. This may seem laughable to some people, but hey, when you're desperate to shoot HD, 50 seconds at a time is better than a non-stop hour of HDV! Can anyone give me some website links to find out how to set up RAM as a disk? Noah, does the Sumix software facilitate copying the RAM file to HDD, or can you simply drag/drop within "My computer"? Is the SMX format a single video file or sequence files?

All the best,
John.

[Oscar Spierenburg]

That is a very interesting question. I also like to know more about that.
When you can only film 50 sec. you'll have to plan carefully what you are filming, that's not a bad thing. It's like shooting on an expensive film stock.

[Carl Jakobsson]

I don't think 50 s is a problem if you're going to film short films and such. It's very seldom a film a take that is more than 30 seconds.

[Wayne Morellini]

You should be able to get 4GB on some laptops, maybe even 8GB. If you want to make a small computer instead, Juan posted a board on the cinema project threads that could do 8GB. They looked at lots of boards on those threads so it is a good way to find manufacturers. One of the problems they had with disk drives was finding a board that could handle the data width over the bus, from pci?/usb bus to hard disk, so it is good that they are on separate subsystems, or that the bus has enough bandwidth to do it.

http://www.win-ent.com/MB-06047.htm

Something rings bells in my head for 16-32GB on a board, maybe, an main board, or maybe a Ram disk like this one: but with more capacity:

http://www.gadgetspy.co.uk/2005/10/0...i-ram-launched

[Rob Lohman]

The maximum you will be able to get over USB2 is 1280 x 720 @ 48 fps (in 8 bit),
in theory you might be able to squeeze out 1920 x 1080 @ 24 fps but I doubt
that'll happen.

To record the first to disk uncompressed in bayer format you need 42.19 MB/s
(or 21.09 MB/s for 24 fps). The second needs 47.46 MB/s.

It is a challenging project, but should be fun. I'm not convinced you can make
it perform good enough in Visual Basic though. When we where looking at it
a while ago we were talking about C and hardcore assembly with SSE / MMX
instructions.

Real-time compression will probably be a must unless you can squeeze in a
hardware RAID system. Doing 10 or 12 bits per color channel is even more
challenging.

Good luck!

p.s. hey Wayne, long time no talk :)

[Wayne Morellini]

OK, see you shortly ;)

[John Wyatt]

Rob, I was thinking of a less ambitious frame size of 1280 x 720 (not 1920 x 1080), though at 10-bit to make a real digital negative (not 8). I thought in RAW this was 27 MBps at 24 fps, maybe I got it wrong? Can someone confirm this datarate, and also the sustained datarate of USB 2.0 to be around 50 MBps in order to accomodate it? One of the Sumix software recording options is RAW to RAM, which takes away the problem of relatively slow HDD's in conventional laptops.

Good to hear from you again Wayne. Thanks for the info about laptop RAM capacities which are greater than I knew. I imagine laptop RAM is more expensive than desktop RAM (?) so on my budget, I'll probably be limited to 2 Gb anyway, but at least I can look forward to more. I was thinking of buying a laptop specifically for RAM recording, so would need to check what the max RAM capacity of the mobo is to avoid upgrade disapointment later.

Carl said: "When you can only film 50 sec. you'll have to plan carefully what you are filming" -- yes, it reminds me of shooting super-8 when I was a kid. Each cartridge lasted about three-and-a-half minutes, so it focuses the mind
somewhat. It was no different when I later had a 16mm wind-up Bolex which used 100 ft rolls. If you actually time 50 seconds it's surprising just how long it is to film a single shot. Certainly, recording separate sound shouldn't be a problem since you probably won't have enough time to lose sync over 50 seconds, though you'll burn up valuable time using a clapperboard marker!

I came across a utility called (appropriately enough) RAMDisk, which may be what we need to divide up RAM and have Windows recognise the extra part as a disk (it costs $49). I found it on the Cenatek website: www.cenatek.com

Thanks everyone,
John.

P.S. Wayne, anything new on the possibility of recording to a portable games consul?

[Wayne Morellini]

Nothing new in that area. It would be possible, but you would have to make special engineering on the hardware bus (though there is a type of device configured to get over the slave on thing I saw somewhere in the last 6 months). Too late, can't think about it at the moment, but you basically lend up using the device as a display.controller to control the disk to make a copy of what is being sent (you could record through a disk connected to the memory card but don't know if that has the bandwidth), But when the smaller PSP comes out and the Gameboy Advanced 2 (we think based on the Gamecube) we should be telling some very nifty hardware. There is the possibility of performing some compression to, but as Sony knocked me back for a developer kit, it might pay to look at the third party opensourced kits out there.

Hmm, there is actually something new, the Gamepark GP32 people are doing another handheld and the Gizmondo people have a similar device/phone also coming. If somebody could hack a camera you could probably get results with a lot less hassle (the sensor's built in, all you need is a drive pack and lens adaptor, not so stupid guys, just think of them as awfully well featured little camera heads).

Now about USB2.0/Ethernet cameras and bandwidth. These industrial cameras use a 16bit word format to send data. So if you send 8bits it will be packed in a 16bit word (is that right Rob) so 22.5MB/s would become 45MB/s (which is close to what you can get out of USB2.0). But I'm pretty sure that it will pack two 8 bits into 16bits, so your back to 22.5MByte/s (I think that is 720p at 24fps). Remember to use Windowing to get a 720p picture, otherwise it will send the whole frame and consume more bandwidth, but you know that already. But what happens if you send 9+bits, you are suddenly are up to the 45MB/s mark again as anything over 8bits get packed with 0's (but I think the Sumix cameras are only 8 bit, make sure that they have the internal Gama curve pallet feature and guaranteed frame timing (locked to frame rate) that they indicated to Ben on the other thread before). But that is not all of your worries, the data does not come out at even speed, between each frame of data, even each line maybe, is various internal processes, including the shutter, So now that nice little 22.5MB/s is suddenly way big, depending on your shutter speed etc. But there is another problem called rolling shutter were the scene will change from the top to bottom line meaning anything that moves will slant in relation to how fast they move and how fast the shutter is (the Ibis models have global shutter which sacrifices light and requires more bandwidth, but good feature) to get rid of this you have to scan the chip faster (48fps is recommended) or use Global shutter. So this all effects how things come out and Can saturate a 100MByte per second PCI capture card trying to capture 24fps. SO make sure that you can trim your shutter/scanning timing to best effect (not going
overboard as that can effect the picture quality).

Now the good news, if you have a good USB2/Firewire/Ethernet camera setup, it will have a memory buffer that will even out the flow, hopefully to a good even 24fps. This will deliver 22.5MByte/s at a rate of 22.5MB/s not at 48MB/s etc If it has pixel packing, then pixels will be packed according to their true size end on end despite the 16bit boundaries (which they will cross with no complications) with no wasted bandwidth. I forget if the Sumix cameras have these. If you look through the project threads you will see discussion on these issues, particularly with Steve Nor.......(can't remember) and engineer/salesman from an rival company, that developed a Altasens raw camera/capture system for less than $10K (much less possibly) after being a here.

It is really late and I am really you know what, so I am sorry if this is a bit messy.

[Rob Lohman]

The real-world maximum of USB(2) depends on a lot of things. So I can't really
say much about that. Okay, let's work out the table for 24 fps @ 1280 x 720
in RAW bayer format:

1280 x 720 = 921 600 bytes per frame (in 8 bits !)
921600 x 24 = 22 118 400 bytes per second (in 8 bits!)

22118400 : 1024 : 1024 = 21.09375 MB/s

That is if you select 8-bit mode. Which you can either select or perhaps use
8-bit log where 10 bits are made to fit into 8 bits, which may be an option to
still get the higher bitdepth but stay at a lower bitrate.

For 10 or 12 bits the camera (head) can do two things. Simply store it as 16
bits or pack it. If it just give you 16 bits (which hopefully an USB head will
*not* do, but only Sumix or the SDK can answer that) you can simply multiply
the numbers by 2:

1 843 200 bytes per frame
44 236 800 bytes per second which is 42.1875 MB/s

However, if it packs the 10 or 12 bits you get:

(1 843 200 : 16) x 10 = 1 152 000 bytes per frame in 10 bit
(1 843 200 : 16) x 12 = 1 382 400 bytes per frame in 12 bit

That's:

27 648 000 bytes per second in 10 bit which is 26.3671875 MB/s
33 177 600 bytes per second in 12 bit which is 31.640625 MB/s

If you count MB (megabytes) by dividing by 1000 instead of 1024 then simply
replace my numbers in the calculations (31.64 MB/s will become 33.18 etc.)

So to give you a table with rounded MB/s for 1280 x 720 @ 24 fps:

8-bit: 21.09 MB/s
10-bit: 26.37 MB/s
12-bit: 31.64 MB/s
16-bit: 42.19 MB/s (if 10 or 12-bit or not packed by the camera head)

Hope that clarifies some stuff

p.s. this assume the data is being send in complete raw bayer form, without
any other stream data as headers or audio etc.

[Rob Lohman]

If you want to see a whole host of resolutions and bandwidths you can
download my Excel sheet from the URL below:

www.visuar.com/DVi/resolutionvsbandwidth.xls
(right-click, save target as)

[John Wyatt]

Wayne and Rob -- thanks for your valuable imput. The way the Sumix camera/software does things is the great mystery at the moment. I'll try and find out more myself, and will be following Noah's tests with interest.

Thanks,
John.

[Noah Yuan-Vogel]

Believe it or not I am actually starting to get some work done on this camera. Unfortunately I have reached an obstacle wherein my original plan for mounting the infrontofthelens IR filter isnt quite a working option since the lens doesnt really mount to the mattebox/filter it only sits in the hole. I am trying to figure out a way to keep the filter mounted without light spilling in between the filter and lens and that still allows me to access the focus ring. Easy solution = get a step up adapter allowing me to directly screw my 62mm filter onto my M35.5 and M40.5 (anyone know what that means in standard filter size terms?) lenses. Problem is I am in morocco and no such thing exists unless i take a trip to casablanca which i just might end up having to do. I've been searching stores for several days for something to solve my problem with no luck. I'm also open to any DIY ideas anyone has for this problem. It is incredibly important that section between the lens and filter is closed to light since the filter is very reflective (reflects IR light, thats how it works) and the sensor very sensitive to IR light. So all light must come from in front of the filter not behind it.

Also, i quickly came up with a few pictures that are now at my newer photo website:
http://community.webshots.com/user/nyvz4
(in the camera project album)

[Oscar Spierenburg]

The camera is starting to look wonderful. Do you only get still frames or have you already captured clips with it?
It's difficult to see from the pictures where the IR filter is. I'd like to help finding a solution though. What's the diameter of the lens, and how far to the front is the focus ring?