On the topic of Pleora boards and the like - there are tons of high quality VGA machine vision cameras lying around... Has anyone worked on a RGB to GigE Vision or IIDC converter ?
Just wondering what it would take - perhaps I could try attempt one myself..


Isn't that 56 MB/s or am I calculating wrong?

Some 2.5" SATA drives can reach 56 MB/s, but only as burst not sustained write speeds.

I believe the best average write speed is about 44 MB/s, will that work with lossless compression so no RAID is needed?


That Pleora board only works with parallel data, maybe they have something else that uses serial... because the Micron is serial, I think?

EDIT: I tried browsing the Micron Datasheet, but I am still unsure if that Pleora will or will not interface.

Does anyone know how the Micron head board interfaces with the dev board?

FYI - Linux allows USB on steroids too :-)
http://www.linux-gamers.net/modules/wiwimod/index.php?page=HOWTO+USBPolling

Windows utility is called USB Mouserate switcher.

A very small PC - looks promising.

http://translate.google.com/translate?u=http%3A%2F%2Fwww.manufactum.de%2Fproduct%2F1413839%2Fgroup%2F189561%2Fdmc_mb3_productlis t_pi1.3699.page%2F1%2Fdmc_mb3_productlist_pi1.3699.num%2F8%2FProduktdetail.1773.0.html&langpair=de%7Cen&hl=en&ie=UTF-8&oe=UTF-8

maybe, but for what? geode cpus are very slow.

So I just finished reflowing the camera chip on to my heard board PCB
http://goosetech.homelinux.com/photo.php?photoid=6

Looks good! I wont be able to get around to coding up the interface for a while (exam week doth approach)

But hopefully over Christmas we'll see the first pictures out of this puppy!

Also, for processors, Im looking at the BF537

Its a 500MHz Analog devices DSP with two built in MAC's which means Ill have a myriad of avenues for encoding.

Did it end move or lost interest?
Just curious as I was waiting for some more info on
any progress.

Since 5 months ago have there been any new chips or revelations?

Bob

I guess Sumix offered what most of us were looking for and as I've got a lot to shoot and little time to do it, I'll just start by buying the 12a2c cam. After that I'll think about finishing this project.

Actually, Im still working away. Ive got my head board working on a logic analyzer implemented inside of the FPGA dev board Im using. This means I can see pixel data in byte form coming from the imager at 48MHz. The current challenge is storing this data stream, so I've been working with a SDRAM (8MB) to buffer a frame so I can attempt to offload it to a PC and get a "frame".

Full time student status makes progress on this task a little slow ;-)

One thing Im also planning is to use experiment with a cypress part (FX2) to stream raw data across USB 2.0.

So is anyone else still working on anything?

Also out of curiosity mainly, would anyone out there be interested in a kit of my final revision of the project?

My current laundry list of pieces for the kit/ final revsion are:
- Blackfin BF537 DSP
- Cyclone II FPGA
- 64MB SDRAM
- some amount of FLASH for firmware...
- 100BaseT ethernet
- MT9T001 Micron Imager

I figure between the blackfin and the DSP blocks in the cyclone there would be more than enough head room to run some good compression schemes to dump the video across ethernet (or USB 2.0)

Im rambling... by for now!

I've been thinking of a great, at least to my knowledge, way to do a digital cinema camera. If you take a magazine from a 16mm(or 35mm for that matter) camera that has the sprocket mechanism in the magazine(Like the NPR) and put all your digital cinema diy products in there you'd esentially have a complete camera for very little money and work.

All the "camera" stuff would already be done in the body. You could just snap on your digital magazine to your body and shoot digitally or your ordinary magazine for film.

Lensmount, shutter, optical viewfinder, you name it in camera. The magazine just holds the sensor, computer, recording media, battery and connectors(Maybe a small lcd on the side for info). You could even have a switch that is switched by the film feeder sprocket so that the computer knows which framerate the camera is running at. Some kind of weird fusion of computer and mechanical age.

Now I do not know how a cmos sensor behaves but imagine that you take information from it at a regular rate, say 24/s, and you have a mechanical rolling shutter in front of it?! If so it seems it would work perfectly with a software that takes information from the sensor every time the switch I wrote about above registers a new frame.

It seems unnesecary to reinvent camera functions for a digital cinema camera when you more easily could just change the media.

You'd esentially just attach your s-16 sized cmos on the pressure plate inside the magazine. (Maybe with some sort of protection that keeps the pressure plate with the cmos inside the magazine until you snap it in place so that you wont scratch the sensor at attachment. Don't know exactly how that would be done but seems doable.)

If you don't have that much money you could just buy a r16 camera and shoot cropped until you can afford to turn it into s16.

Now I might be missing some major problems here as I'm not a sensor expert by any means but to me it seems like the perfect solution.

Alex, may I ask if you're already controlling the sensor with the FPGA, why do you need a computer? The ideal solution would be to have an independent camera.

Klas -- I remember several years ago there was an attempt to convert 35mm SLR still cameras to digital by placing a panel-type unit (which had a sensor in it) into the standard 35mm pressure plate of the camera. I think the product changed names at least once but was called something like "efilm" or "SiliconFilm". The product didn't really take off when DSLRs became more affordable. I wonder if we could use an idea like that: just take an SLR still camera body and find a sensor which could be mounted in there, cabled out for dumping the data to a laptop or small computer? Like a glorifed webcam. I know some of these left field ideas are more problematic than just getting an existing video camera! But I think the spirit of these Alt Imaging threads is to ask questions and see if there's equipment and components out there, probably designed for other purposes, that might be used in some way to create DIY cameras (at a low cost). Sometimes I think a camera producing distinctive images can be more interesting than commercial cameras that produce technically better images, though obviously it depends on the type of projects you have in mind for them.

I have 2 old canon SLR cameras ready... If we place the sensor in the right position we'd also have autofocus if needed.

The only problem I see is that this is just a case. We'd still need either an APS-C or a full35mm sensor + sensor head + FPGA or similar to have the camera.

Position accuracy is critical for the sensor. Without absolute perpendicularity of the sensor to the optical access the camera will not work for short depth of focus as you will have focus on one side and not on the other side. You must have laser autocollimator to adjust position accuracy to several microns for any quality camera. Protecting sensor from noise is even more difficult and only an art. Any noise on the power supply feeding the sensor will show in the images.

Yes, that's another problem...

But again, the main problem is not the case, the main problem is getting the camera to work.

“This is just a case. We'd still need either an APS-C or a full35mm sensor + sensor head + FPGA” -- I agree. It depends how far back along the process you begin: if you start with a board/sensor, putting it inside an existing camera with a known lens system might be a step forward (though as Farhad says, alignment accuracy might exceed what an amateur can achieve). If you start with a camerahead, you already have all that and will be looking at data writing storage solutions, software, codecs, etc. The way forward for DIY cameras (the best start point) still seems unclear.

I once took apart a cheap webcam and put the sensor inside a 35mm SLR, but I couldn't get a good picture!

Position accuracy is critical for the sensor. Without absolute perpendicularity of the sensor to the optical access the camera will not work for short depth of focus as you will have focus on one side and not on the other side.

Though by placing it on the pressure plate it would be on the exactly same place as the film frame would. So the accuracy is already done for you in a way.
Though the sensor is a bit thicker than film i guess so you're right, there would probably be some adjustments needed to get the right focal plane. But that could be done by measuring and checking where your focus is if you could do some smart micro collimation, like on the Brevis.

As for still photo adapters, they do exist. Not for your regular nikon but Hasselblad has some digital backs that you can attach to your old film cameras.

I'm considering having a shot at this with MT9P401 sensor and cy7c68013a usb
2.0 chip. From what I've read from cy7c68013a datasheet, it should be possible
to plug it directly to MT9P401(using gpif), so there is really no need for fpga.
This chip runs at 48 MHz so 1440*1080@30fps is max.
Would be nice to know if MT9P401 is pin compatible with MT9P031...

You can't use huffyuv
or similar algorithms (effectively) unless you perform debayering, so I think it's
probably better to work on bayerized data.
So I have been considering
http://www.eurasip.org/Proceedings/Eusipco/Eusipco2007/Papers/a5p-j05.pdf /
http://ltswww.epfl.ch/ltsftp/ICIP2007/pdfs/0200353.pdf .
Problem with this is that it's quite computationally heavy algorithm at
these data rates. I'm also little worried that blackfin might not have
enough wide io for sram to run this kind of compression. Rates are 253.68 MB/s
for blackfin with 16 bit bus clocked at 133 MHz and 381.47 MB/s for TMS320C6413
with 32 bit bus clocked at 100 MHz(max allowed). It probably takes something
like 5 times the input data rate to run this kind of compression algorithm.

Also, I do not yet know whether it's computationally possible to do this in real-time. TMS320C6413
at max speed would give 32 MMACS per pixel for 1920*1080@30fps assuming all
operations work on 16 bit data. Double that for 8 bit data.
Compression ratio is about 0.5 - 0.6 on "average" case. Probably
something like 0.3 - 0.4 if compressing delta between predicted and past frames with this
algo. I haven't yet implemented the ffmpeg codec so I don't know what
the exact compression ratios would be for video.
The big problem with lossless compression is that compression cannot be guaranteed
if the scene is just too complex.

Final version would probably have:
-some fast dsp
-sony psp screen
-arm7 cpu
-sata/ide hd
-http://www.dealextreme.com/details.dx/sku.7533

It's very unlikely final version becomes reality though.

Hey, that sounds really good!

I have a few questions:

- Why 30fps? If we're trying to build a cinema camera we'd need 24fps.
- Are other resolutions possible? You talk about 1440x1080. What about 1920x800@24fps?
- Is this a pc-less camera?

- Lossless compression would be good but it's not a must. Low lossy compression is ok too if it stays between 4:1 and 8:1. New versions of Cineform are 4:1 and the RED One compresses even more. What about Motion JPEG2000? And visually lossless RAW?

- Are you considering sharing the cy7c68013a code you write with the community, so everyone can buy all the parts needed and build a working cam?

- What can I do to make your life easier?

Thanks a lot. It really looks like we're finally getting somewhere.

1920*800*24/1000000 would be 36.864 MHz which is fine as well. In theory, any resolution and fps with w*h*fps/1000000 < 48 should be fine. Bits per pixel is limited by transfering speed of usb 2.0. I'm not sure how advanced cy7c68013a is so only 8 bpp and 16 bpp(remaining ignored) could be possible.
First version having cy7c68013a would plug to usb port. Second version would probably have cy7c68013a as well.
cy7c68013a is the same cypress FX2 Alex Stewart was talking about earlier.

According to that paper, JPEG2000 compression ratio isn't as good as with this algo. I'm not familiar with JPEG2000 but I'd think it's also computationally more intensive than this. One candidate for near lossy compression could be
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/9711/30651/01415418.pdf?temp=x . I do not have access to ieee so I couldn't tell.
It might be possible to come up with a good(fast) lossy algo by taking some of ideas proposed in papers I posted earlier.
It's not the compression ratio thats the big problem here, its finding a algo that can achieve ~0.5(fixed) compression ratio using low cost and easily available components. More simpler compression algo means there will be less compression. TMS320C6413 costs about 25 euro, which is about as high I'm willing to go.

Anyway, building a standalone compressing version is way more difficult and time consuming than just plugging a sensor to pc via usb. I'd hate to be realistic here, but this project will probably die once the usb version is done.
Compressing version would require team work and a plan that everyone interested agrees to. Alex Stewart's version is too complex and expensive for me.
MT9P401 pin layout is my main concern now.

BTW, Alex Stewart got picture.

Had another look at dsps and found TMS320DM6441. It's little faster than TMS320C6413 and has arm9 cpu, usb 2.0, ata, 100 mb emac, and ddr2 interface. Also has all sorts of jingle bells meant for video processing. At 30 euro it seems like a good candidate. This one has 0.8mm ball pitch while TMS320C6413 has 1.0mm. Ball layout looks much worse than TMS320C6413's.

You can't use huffyuv
or similar algorithms (effectively) unless you perform debayering, so I think it's
probably better to work on bayerized data.


Why not adjusting huffyuv to work with bayerized data? It wouln't be too difficult and one could avoid propable patent issues...

you can easily modify Huffyuv to work with bayer, just assume you are feeding it a 32 bit image.You just get 4 planes of a quarter resolution, two of green, 1 red, and 1 blue.The problem is you will get limited to 8 bit per color channel and you will also need to generate new statistical Huffman tables for the new data.

And some of the prediction schemes would not work as well because physical distance between comparable pixels is higher. You also couldn't perform conversion to color difference domain(r-g, b-g) since you have no green pixel at that position. Simple debayering on those pixels might work but I doubt you'd get as good compression as with huffyuv. It might still be a good solution especially considering how simple/fast huffyuv actually is.

I'm not that worried about the possible patent issues since most aspects of it can be replaced with similar methods. Only the context prediction scheme is really important. Need to ask about that.
I got my modified version to run at 3 fps on my core duo@1.8 GHz(using one core) without mmx, sse, etc. optimizations, so it doesn't seem to be fast enough. gpgpu implementation would probably be fast enough for compression. Decompression doesn't parallelize that well so it would be slower.

Anyway, I realized there is really no point in doing compression on standalone version because modern computers can't perform real-time compression to any reasonable format anyway. That is, unless you have some other reason to cut bandwidth requirements. Cheapo hard drives can write ~70-50 MB/s (depending on head position) which would be enough. I'm wondering if it would be possible to directly drive hd with arm7 cpu and sensor. Blanking times could be used to perform activity on hd with arm7(assuming it's fast enough to react :) . It would require that ata drives can accept several sectors of data without intervention between frames.
According to http://home.nikocity.de/andymon/hfg/Alya/alya.html , 8 bit mode might not be supported on modern drives. LCD would need fpga or clpd though.

Checking resistances on mt9p401 revealed that it is likely pin-compatible with mt9p031.

Long time no post for me.... Since my last post I've graduated college, found a paying job, and gotten ready for my wedding... Which is this Saturday :)

And also as I'm sure some of you noticed I got my system to cough up a image !!!
The color is awful because the i2c bus is not hooked up ( is I'm using 100% default gains and white balance). I did not make much progress do to a nasty kernal panic that the ppi driver on the blackfin would kick out..... Hapiily that issue is solved now.

So!! At the moment I'm rigging the i2c bus up so I can mess with the gain, then I'll be piping my data into vlc to stream some video.

This is mainly for debugging, the bf can only encode at about 10 fps into mp4 at this res,
Once that works I'll be attaching a hdmi and IDE interface to the blackfin.
Piping in on archecture of my system, the idea is for the Fpga to do the heavy lifting ( ie decode the bayer, and convert to yuv) so the data stream from the Fpga will be raw full res yuv data, this gets piped into two adv202"s which plop out a jpg2000 frame that the DSP' dumps to storage medium .... Or streams acrosss Ethernet...

The nice thing is, if say I want to aide in compression , the dsp' has enough ummf but so foes the Fpga....

Hince the hardware, once I'm done, it's modular enough to support just about any software and cinema work flow you could think of....

( ps.... I plan to sell the boards at $600 ea)
(pps.... My genious 3d animator brother is also doing up a spiffy case I'll have milled out of billet Al. ........ Red one here I come :p )


Please forgive the horrid spelling and formatting, I'm typing this on a iPod touch since my laptop is in a box.... Somewhere.....

( sad thing is I can ping it... So I know it's near ...,.)

By or now folks !!! I'll be back with hopefully some video clips in about three weeks

:)

Waiting for some equipment so I can make the pcbs.

just wondering if anyone has compared the Ibis sensor Marlin F-131c cameras with a HV20 to compare quality ? I'm sure its worse than the CCD MVC's but how does it compare to consumer HD camcorders ?

Thanks!

The Marlin F-131C uses the ibis-5a sensor. Search the board for info. Ibis-5a is an "industrial type" sensor used by sumix, avt, silicon imaging, pixelink, etc. in some of there cameras.

Not very good color performance, but global shutter and shallow DOF are a plus.

I am developing DI editing, color correction, sound mixing, and filmout to 35mm movie film software for use with DIY Digital Cinema cameras.

I was wondering if someone has a list of uncompressed cameras that can shoot RAW sensor data better than 8bits, 1280x720p or better at exactly 24fps for sync sound shooting?

The Aptina MT9P401I12STC sensor seems like a good choice for such a camera, could you summarize the current status of your project, and how others could get results usable for Digital Cinema like the results you are getting, i.e. what needs to be purchased, who do you get it from, what softwares need to be loaded and how one gets the settings right?

Anyone who has a Digital Cinema camera that is in a state that lets them shoot 1280x720p or more, 24fps, 12bit or so, RAW sensor data please e-mail me directly so we can stay in contact as I develop my post production system more, I would like to develop some extra software de-Bayer and such to support low cost Digital Cinema cameras so users/"Beta Testers" of my programs would have more low cost Digital Cinema camera options.

If you have any questions about my "freeish" software or need support using it with DIY Digital Cinema cameras feel free to e-mail me directly or through here.

Dan Hudgins
tempnulbox [at] yahoo [dot] com
The official DANCAD3D (tm) Beta Test Web site. (http://www.DANCAD3D.com)

I may also be able to help with some suggestions for some circuit/firmware additions to aid in having your camera work well with my programs and in general for use as a Digital Cinema camera.

I have been thinking that it would be useful to make a Digital Cinema camera based on the Aptina MT9P401I12STC sensor to get 2592x1102x12bit@24fps and 2048x1152x12bit@24fps RAW sensor data. If you cannot get 2592x1102 to work then 2560x1080 may.

At any rate, to overcome the limits of the USB speed, you can build a "shoot and dump" camera that has enough FLASH or DRAM to store about a minute of shooting as RAW 12bit sensor data, then after the shot is finished the data in the buffer can be downloaded through the slow USB.

What that gets you is high quality images without any problems with the computer's harddisk speed or dropped frames.

A maximum record time of one minute per shot is fine for feature filmmaking since normal feature films do not have any single shots longer than one minute, as edited in the finished film.

If you make the buffer memory swapable, you can run the camera in two modes, "shoot and dump" or "shoot and swap". If you are shooting in "shoot and swap" mode you can put the buffer card back in to download it later. Being able to also swap lets you shoot many takes rapidly, than download them later. Being able to "shoot and dump" lets you download while you are setting up for the next take. The download time would only be about three or four times the shoot time so it should work well.

Such a camera could be an open project so that various people could make improvements to the PCB circuit and layout.

I would be interested in both using such a camera to help with my Digital Cinema software development, and to support such a camera for use with the DI software I am developing.

The reason for trying for 2592x1102x12bit@24fps is to be able to down size and squeeze the images for 35mm filmout using my film recorder program to get fewer artifacts in the end result, and to use the largest sensor area possible to overcome the resolution issues of the C/CS mount lenses that can be used.

Please feel free to e-mail me about such a camera, or anything that can shoot well at 24fps true RAW sensor data at more than 8 bits and high resolution. I would like to develop working workflows for such cameras so that people can use the cameras that work well with my programs. I have tested my suggested workflow for the RED ONE (tm) Digital Cinema camera, and have a suggested workflow for the Acam dII (tm) camera on my Web site, but I will need to wait for sample DNG frame sets from Acam dII (tm) to confirm that it works or to make adjustments. At any rate, it should not be too hard to add other RAW mode camera's to the supported workflows.

Dan Hudgins
tempnulbox [at] yahoo [dot] com
The official DANCAD3D (tm) Beta Test Web site. (http://www.DANCAD3D.com)

Thanks to the DVINFO readers that have contacted me about my software and the subject of uncompressed cameras using the Aptina sensors. I expect there will be some more developments in this area, if you know of a camera project that might be useful with my DI system please let me know more so I can look into what cameras would be a good choice for doing Digital Cinema with the software I am developing to help people make motion pictures digitally... I have been doing some tests with my DANCINEL.EXE (tm) program to transfer digital frames to 35mm movie print stock, and by using my "spread gamma" feature the results look good so far shooting off a 1600x1200 LCD monitor with time exposures of about 4 seconds and longer, depending on the filters used and the f/stop of the lens. My film recorder program also supports CRT monitors up to 2048x1536x32bpp (24bpp+8bits padding, as thats the way the video boards work.)

As a follow up to my post about doing some filmout tests, I found that a ROSCO #22 filter (redish orange) gives close to color balance for 35mm Eastman Kodak Vision color print film 2383 2393 stock shooting off a LCD 1600x1200 monitor. The total exposure time is about 120 to 180 seconds at T/2.8, when using my DANCINEL.EXE (tm) in three exposure "gamma spread" mode you set the animation motor delay to 45 to 60 seconds. For printing black and white on Eastman Kodak 2302 the exposure is about 4 x 3 seconds (12 seconds total) at T/8 with no filter. The main problem shooting color printstock of a monitor is the lack of RED light, I am looking into ways to deal with this issue, but for now you can use tri-color or color seperation modes if you have the time. If you want help with the gamma adjustments feel free to contact me, my email is above etc.

Are there any DIY Digital Cinema Camera projects with uncompressed true RAW sensor data under-development now?

I have been working on de-Bayer software to go with my freeish DI/NLE/CC/MIX software I am working on, and if anyone has sample sensor data RAW files, I can look into adding support for their camera(s) before I release my new program, maybe this summer or so.

I have updated my "freeish" NLE's CC control screens to work better on some Windows XP Home (tm) computers that had issues with the higher resolution video modes, its up on my web site for download now. It works with frame files up to 6K or more.

Dan Hudgins
tempnulbox [at] yahoo [dot] com
The official DANCAD3D (tm) Beta Test Web site. (http://www.DANCAD3D.com)
San Francisco, CA USA

Hi,

Things are moving forward on the software and camera front, I was talking to Jose A. Garcia, but did not hear from him on my last email, has anyone heard from him in the last few months?

Thanks for any info you have, since this was his project thread I thought I would let him know about some developments, which I can't go into in public quite yet.

Dan Hudgins
tempbulbox [at] yahoo [dot] com
The official DANCAD3D (tm) Beta Test Web site. (http://www.DANCAD3D.com)
San Francisco, CA USA

Dan, have you seen the newly announced USB3 cameras from Point Grey?

Point Grey | The World's First USB 3.0 Camera (http://www.ptgrey.com/usb3/#/flea3_usb_3.0_camera/point_grey's_flea_3_usb_3.0_hd_digital_video_camera)

Preliminary pricing on the 32S2 model will be about $800US and the 63S4 will be around $2000US.

Hi Arnie,

Thanks for the link about the USB 3.0 camera.

I made a SSD test program and some people there with fast computers were able to record it seems 2592x1102x12bit @ 24fps using two SSD on a RAID.

There may be some glitch issues, and a 64bit OS may work better with a quad core, but it might work. With "normal" older computers it may be hard to record above about 1280x720p uncompressed.

Cabled cameras are a bit harder to use in the field, but for studio use it could work.

The de-Bayer program I have been working on for Cinema use it getting close to release.

Someone sent me a SUMIX RAW file, but is was not uncompressed "RAW" it was poorly white balanced, gamma adjusted, and noise filtered. Once the sensor data is mucked up, you cannot un-do that. It seems you have to go into the SUMIX software and check and uncheck some things before it saves actual RAW sensor data in 12bits format.

If someone has a real 12bit RAW SUMIX file, I would like to look at that data and it would help me with the presets for the de-Bayer processing. I do have the commands to break-up the SUMIX RAW into RAW frames, for shots up to 2GB long. And they gave me their 12bit packing method so I can un-pack using that, although I need real RAW sensor data to check and see if everything is working right. at 1920x1080x1.5bytes per pixel at 24fps, 2GB is, 26 seconds, so that is enough to shoot a movie as few if any shots are longer than that. With other cameras that shoot RAW frames, there is no "limit" as my program can process shots over an hour long that way.

I also have support for SI-2K (through their DNG convertor), Kinor-2K (as DNG), ACAM dII (as DNG), and some other cameras that make RAW but are not on the market yet.

My de-Bayer should be able to process any normal 8, 12, or 16 bit RAW Bayer or monochrome data to BMP 8/24bpp, DPX 10/16bpc, CIN 10bpc, or TIF 16bpc.

Anyway, if you know any other low cost cameras that can shoot RAW at 24fps, please let me know so I can look into supporting them also if I am able. When I get my de-Bayer program posted on my Web site it will be a free download for "beta testing", between now and then people can contact me about supporting cameras or doing sample conversions.

I was talking to Jose A. Garcia about making his type of camera "real" but have not heard from him for a while, but there has been progress...

The USB camera is really interesting. I'm wondering how much work it would be to push everything (processing and controls) into software, and replace all the expensive proprietary hardware with commodity parts.

If you could bundle up a simple board to convert the raw signal to (say) Adobe's Cinema DNG, control the camera, and feed a RAID system then it would be possible to build a small, lightweight rig.

However it's probably worth keeping an eye on Intel's Thunderbolt / Lightpeak technology which is even faster than USB 3.0. And if they ever release the optical version, you could have a 100 metre cable, which gives a tethered camera a lot of flexibility.

The Register has some coverage.

Intel throws Thunderbolt ? The Register (http://www.theregister.co.uk/2011/02/24/intel_thunderbolt/)
Intel: 'PC makers took the light out of Light Peak' ? The Register (http://www.theregister.co.uk/2011/02/24/intel_thunderbolt_copper_embrace_explained/)

And there's the Intel product page for the truly geeky...

Thunderbolt Technology (http://www.intel.com/technology/io/thunderbolt/index.htm)

Dan, are you aware of the Elphel cameras & the Apertus opens source cinema project that's affiliated with it? I think that Elphel is currently using an Aptina sensor. The camera is open hardware with open source software. Apertus is trying to develop the software along with an open hardware controller.

Elphel, Inc. | Imaging solutions with Free software and open hardware (http://www3.elphel.com/index.php)
Home page | Apertus - Open Source Cinema (http://cinema.elphel.com/)

Quote: [Graeme Sutherland, If you could bundle up a simple board to convert the raw signal to (say) Adobe's Cinema DNG, control the camera, and feed a RAID system then it would be possible to build a small, lightweight rig.]

The new software I plan to release soon already converts True RAW sensor data to DNG, and also does bad pixel removal (interpolation) and FPN subtraction.

The main problem with DNG is Tag 50721 XYZ to RGB color matrix. There does not seem to be any document that tells how to find the right XYZ values based on shooting test charts. It is possable to guess the "right" matrix values, but the results from DNG conversion are not good.

Direct conversion to 16bpc DPX and TIF files is a MUCH better option than doing anything with DNG files for output.

I also have DNG input, but use it as RAW data and ignore the tags that just muck up the image processing and use my own "film-like" processing video path that seems to be producing results better than what I have seen posted from DNG conversion in other programs. I sent some samples to Acam dII of their sample DNG data and asked for permission to show my version of their images but have not heard anything back from them. When my program is out you may be able to use it to process the Acam dII sample DNG files and see for yourself if any other DNG convertor does a better job, if you find one let me know I would like to look at what you think looks better about their conversion. My processing is full manual adjustment, which can help avoid issues with pink highlights and such.

If anyone has their own Acam dII (or any other True RAW cinema camera) and wants me to do a sample conversion for them they can contact me.

The main problem with recording on a computer is the speed of the SSD, and the glitches caused by the OS and hardware being interrupted. An all hardware solution using CF card array would make a much more compact camera. The software support I have developed solves all of the image processing issues once you save the true sensor data without glitches.

Quote: [Arnie Schlissel, Dan, are you aware of the Elphel cameras & the Apertus...]

I spoke to them on their forum about adding a True RAW 12bit port to their 8bit compressed camera so that the full 12bit sensor data could be extracted for recording on an external recorder using DRAM. It seems they were not interested in talking with me about what would be needed for producing a True RAW recording camera. Major camera makers are going to 12 and 14 bits, their inisting that 8 bits is "all that is needed" or whatever they say is non productive as far as where my projects are headed.

More than 8 bits are needed just to hide all banding in Digital Images, and if you are going to grade with heavy ISO boost and S-curves then there is no other result than histogram gaps if you start with just 8 bits. 8 bit linear data will not even gamma correct to 2.2 without gaps opening in the shadow areas.

Also it is not a good idea to try to de-Bayer compressed data, and any claim that the compression is 100% lossless (no change to the sensor data ADC values) at compression ratios of 10:1 or more (compaired to the packed sensor data bits or delta encoding) is just out of the picture.

If they want to take all the compression "stuff" out of their design and record the actual sensor data as is 100% un-altered, and save it as is to a file named RAW, in numbered frame files like,

00000000.RAW
00000001.RAW
00000002.RAW

Then all that is needed after I release my new de-Bayer program is to enter the RAW setup values for un-supported cameras in the manual setup prompt with values like:

X pixel size
Y pixel size
Data format, 8, 12 (two types supported now), or 16 bits
Bytes per pixel, 1, 1.5, 2
Shift Left for MSB aligment

and so on.

There are prompts for X and Y mirror and Bayer order as some sensors use various starting color pixel.

I just added support for SUMIX (tm) cameras, but when I asked SUMIX (tm) for some sample True RAW sensor data samples shot under calibrated lighting they did not reply as far as I know. Someone sent me a sample that had: gamma correction and clipping, white balance done badly, median filter noise reduction, and such done to the data, so there is nothing I can do with that to make a Preset for that camera yet, someone would need to send me a sample of actual RAW sensor data, not Bayer data that has been "goofed" with and so is unusable for extracting my idea of quality results.

==

I was talking to Jose A. Garcia about the camera development, has anyone heard from him lately?

I am a Documentary shooter, so while I am always excited about these projects, the wind comes out of my sails at the talk of any kind of tethering. This is my question: Why can't we just connect a 2.5" SSD housing to these cameras to capture the data stream? Is there some way to pre-load whatever software controls are on the PC into an on-board card (and eliminate the PC entirely)?

What I am looking for is an ENG camera that uses SSD's as a capture medium, and takes advantage of the fast transfer speeds to decrease compression a little bit and increase the bitrate of the footage. Can one of the knowledgeable in this forum help me understand what is missing?

I don't think there is any reason that such a camera could not be made...

For ENG use though rolling shutter issues need to be delt with, by shooting at 48 or 72fps for 24fps results, or using a sensor with a global shutter which can increase the camera cost. For tripod use where the camera does not move fast (such as for some kinds of feature film making), the rolling shutter is less of an issue at 180 degrees...

The main issue that has come up with talking with various camera makers working on True RAW recording cameras is that they seem to not want to make a "shoot-then-dump" camera because the concept of a camera that has a maximum record time of 30 seconds seems limiting the market for the camera.

But for feature film production all you need is a camera that can shoot shots up to 30 seconds, as very few movies have any shots longer than 30 seconds.

So it seems the lowest cost Digital Cinema Camera would be one that is like a web cam, but has a 30 second buffer built in using DRAM since FLASH memory can wear out over time. DRAM also can have an advantage in that it may have no bad addresses, FLASH generally requires mapping the bad addresses which makes its implementation more complex.

Since all the True RAW data writes to the buffer, the link to download the data in non-real-time can be slower than the ADC output, so even USB/LAN can be used for 2.5K data.

A net-book can read a sub-sample of the data flow from the sensor to the buffer as the monitor display, then download the data after the buffer is full or a shot is finished, passing that data on to an external TB HDD plugged into another USB port etc.

Without a buffer between the sensor and the downloading computer, it is very hard to record on a "light weight" computer full uncompressed sensor data.

After having worked with uncompressed sensor data in the de-Bayer program I am developing, I think its better than various compressed data formats in that there are NO extra artifacts added, and its not that hard to deal with the time and cost of working with uncompressed DI now that TB disks are falling in price so much and second hand computers for the "render farm" are fast enough to get the work done in less than a year.

If you were cutting the picture (workprint and then negative conform) and sound (multi-track magfilm) yourself it would probably take longer than making an uncompressed DI at home, and the DI will probably give you better results in the end since you would not have as much dust and scratches etc. It still takes time to sort through the thousands of shots and sound takes and get things right no matter if you are working with film or in digital frames, at least if you want the best results you can get DIY.

But for feature film production all you need is a camera that can shoot shots up to 30 seconds, as very few movies have any shots longer than 30 seconds.

Many of the 30 second shots are pulled from much longer shots when editing though... I would pass on this camera based on this one thing due to the fact that I couldn't get enough coverage for editing.

It's just an opinion, so don't take my editorial as law, other people shoot differently... but this is standard practice from what I know of Hollywood shooting, so it may impact how you develop the camera's recording system.

I under stand the issue, but with a story board you can interupt the "longer" take into the parts that will actually be used.

As a micro-budget filmmaker I am faced with getting something that in the end looks like a major studio production but with tools and methods that cut out all the fat.

The idea is to make a buffered camera that can sell for about $250 and can shoot 2.5K 2.35:1 ratio and give good enough results to transfer on a DIY film recorder to 35mm color print stock, or to make a DCP with the CCed 2048x858 DPX or TIF frames.

I have written the software to do most of that so far, I have a few improvements to make to the DIY film recorder software DANCINEL.EXE (tm), but its usable as is and the results of our tests watching the 35mm film projected look usable (it requires making more than one pass in the exposure to get better than 8 bit monitor limits onto the film stock).

If I am faced with shooting 35mm short ends or 35mm color print stock and paying maybe $50000 for film and processing, vs. shooting with a $250 shoot then dump camera that has double the shooting time of a spring wound 35mm Eyemo, and maybe getting better results with the $250 camera because of the freedom of dust and scratches, then I could put up with 30 seconds shot lengths.

There is no reason you cannot make the buffer large enough to record 4 minutes which is about equal to the length of a 400' 35mm film load which is standard for filmmaking. But you would need to pay more for the larger buffer memory, so its up to the filmmaker if he wants to pay for 10x the memory he needs to make a 7 second shot.

The optimum cost vs. end result comes it at about a minimum of a 30 second buffer, since very few shots in major motion pictures are longer than that, and with an auto-clapper-slate you don't need to waste frames on slating which can be done when the frames are de-Bayered.

I have a "freeish" DI system written for working with uncompressed workflows, and will have my de-Bayer and image processing program out soon hopefully, so there is support for low cost Ture RAW recording cameras in the pipeline. People can also use my system with RED, ARRI, etc. and HDSLR cameras if they like, as well as film scans. The goal is to get good results that don't look, and sound, like they were made with a cheep compressed camcorder while not spending money that is not needed to get that result.

Unfortunately, you have to deal with actors and they don't switch performances on and off into neat 30 second segments. This will an even larger problem with the actors that you'll have available for an extremely low budget film that involves dialogue. It's not impossible for scenes just involving action, it's about the same as a clockwork motor on film cameras, but for dialogue I'd make 60 seconds,if not longer, as a more practical minimum figure.

You got your wish, well almost, the KineRAW-S8p (tm) is not on sale yet, but I was able to shoot some test footage for development of my free de-Bayer program DANCINEC.EXE v0.04 (tm). You can view the test at this link on Vimeo,

KineRAW-S8p (tm) lens test reel #A2 w/o links on Vimeo

Its shot 2592x1104x12bit@24fps 100% uncompressed True RAW, my software removes the bad pixels and does the FPN masking. The bandwidth was 103MB/s recording to a 60GB SSD.

60000/103 = 582 seconds or 582/60 = about 9.7minutes for the maximum shot length.

With larger SSD the record time can be longer.

The camera has two hot swap slots so there may be a firmware upgrade later that could allow non-stop recording if you swap disks during shooting, but as far as I know they have not done that yet.

As the compressed images on vimeo show losses, if you want to look at some uncompressed BMP frames from that video you can email me with "DVinfo request for uncompressed frames" in the subject line so I do not delete your email as junk.

It great that after so many years Jose's vision has gotten close to being true, if anyone is in contact with him please ask him to email me again so I can tell him about the S8, as well as the S16 and S35 models in development now.

I'm not involved with Kinefinity.com sales so you would need to contact them directly for information about when the S8 would be available. I'm just interested in supporting various DNG (CinemaDNG) type cameras that record full bandwidth uncompressed True RAW Bayer data in my free de-Bayer program for use in my freeish DI/NLE/CC/MIX software DANCAD87.EXE (tm). My programs are up on my web site for download now, and I am working on some updates that I hope to have out early next year.

The video above is a collection of some de-Bayer and lens correction tests, I was also testing my 'film look" processing so the goal was not 'accurate' color as that would tend to make the results look 'camcorder' like, rather was going for a 35mm film replacement look for use in a project I hope to shoot next year for showing in movie theaters quality. I have a more developed version of my DANCINEL.EXE (tm) program for a DIY 35mm film recorder but that is not released yet, although there is the previous version up for download now. I have some things to finish and test in the new version that adds new functions and higher image quality.

The shot with the woman walking the dog was shot non-stop and then cut up, so the length of the shots in the edit is shorter than the shot length made in the camera.

Here is what I wrote on the video's Vimeo page:

Quote: [I am testing various lenses for use in film-making projects using the Super8 format Digital Cinema Camera called the KineRAW-S8p (tm). This camera records fully uncompressed at various Ultra-HD resolutions, this video was shot at 2592x1104x12bit@24.000fps 103MB/s to high speed SSD in the camera. The camera can dump the SSD to a notebook HDD in the camera so my setup was 60GB SSD and 500GB HDD for these lens tests. The camera can take C mount, CS mount, and D mount (regular 8mm) lenses. The image area varies with the resolution mode, some modes are about Super8 size so C mount lenses made for Super8 cameras may be used. the frames were processed in a free program called DANCINEC.EXE (tm) that is on my web site for download and "beta-testing". The workflow was DNG to TIF, the TIF were edited in my 'freeish' DI/NLE/CC/MIX software DANCAD87.EXE (tm) and output as BMP frame set letterboxed 1920x1080, that was converted into a MPEG4v2 6000kbps AVI in VirtualDub (tm) and upladed here. There is no sound on this reel, although the camera can record sync sound 48000 s/s stereo, and has an autoslate beep and SMPTE TIME CODE for sync with an external sound recorder or SMPTE slate etc. The camera used is a pre-production prototype that I am testing for use with my free de-Bayer software, and for use in my own filmmaking projects. The production cameras may be somewhat different from this test camera and I may be able to improve the results that my de-Bayer program produces as I am still experimenting with various filter adjustments and code developments. this was processed mostly with v0.04 while it was being worked on. If you have any thoughts or questions about the de-Bayer you can email me through the address at my program's web site. You can google KineRAW (tm) to read more about the camera development, I am not involved in sales of the cameras, just trying to work with them to support their and other companies DNG recroding Digital Cinema Cameras. You can google DANCAD3D to find my web site.]

In case you don't see that, what I see in this post is the vimeo player showing here, rather than just a link to the video page(?).

I posted a second lens test reel on Vimeo from DNG frames shot 2592x1104x12bit@24.000fps 100% uncompressed CinemaDNG type DNG frames, here is the link,

KineRAW-S8p (tm) 2.5K lens test reel B1 on Vimeo

If you have questions you can ask on the videos page or email me with 'DVinfo user question' in the subject line of your email so I know its not junk, thanks.

Progress seems to being made on all three cameras, the S35, S16 CCD, and the S8. You can contact Kinefinity (tm) about their KineRAW (tm) camera development by email at the contact on their web site if you have an interest and questions. While the camera development has expanded past the original DIY project this thread was started for, Jose's vision of a uncompressed S8 as well as S16 and S35 camera continues to the goal of an affordable solution for filmmakers.

Great work you're doing here, Dan. I periodically check out the Kinefinity website but there's still not much change. Any news on when the cameras will be for sale? And will the S8 model really be around $250?

Cheers.

Last I heard was that the production KineRAW-S8 (tm) with HDMI 1280x720 output and DNG recording to 2.5" SSD was going for a target of about 1/4 the S35 price which has a target of about $6000-$8000, so would be about $1500-$2000 if that follows through.

Anything close to $250-$499 would be a web cam like camera that would plug into a notebook computer, the images would be the same but its not a self-contained camera that way. I've mentioned that concept to them but there is no target date for such a camera for sale. An unbuffered test camera was made some years ago, but that did not shoot at up to 25fps like the self contained one does because it did not have a large buffer, you can see my comments on such a concept camera above in this thread here on DVinfo. The general feeling is that such a low cost camera for filmmaking would not be of interest to many people because of the buffer limiting the shot length to maybe 30 to 60 seconds, even though that is more than the spring on cameras like the Bolex, Eyemo, and Filmo that are or at least were used by many filmmakers that shot on film.

Most of the shots I have been making with the KineRAW-S8p (tm) prototype are shorter than one minute, so for the kind of filmmaking I'm doing it would I think be usable, if not ideal, and you could get 2.5K just like in the sample videos I made on Vimeo, so the main difference between the self contained camera and a web cam plug in for a note book would be the maximum shot length, and being able to have full resolution playback with zoom, waveforms and histograms. The viewfinder and playback on the laptop would be more limited since the self contained camera has very fast hardwired circuits for the viewfinder that allow for playback with the 100% or 200% zoom and region of interest being able to be moved around during playback so you can check focus and exposure etc.

What are your thoughts on a self contained Digital Cinema Camera vs. a lower cost web cam like camera if the image quality is the same and the cost as gone into?

Do you think there is a market for both types of S8 format 2.5K C, CS, D mount lens camera?

You can write to them about the sales dates if you like there is an email on their web site. Last I heard they are trying to get the KineRAW-S35 (tm) into field testing by April 2012, they are having several prototypes made at the factory now and if those are working right testing could begin in a few weeks time. What I have heard so far, is that sales would begin after testing has worked out in China first, so to purchase an early one you would probably need to be in China, after that you will just have to follow along and see what and when things work out.

If anyone has experience hacking the GH1 or other cameras on the sensor pin-out level, if you can get in contact with me and are willing to share your information with OptimaCine.com (sm) so they can engineer an adapter to connect the GH1 or other commercial camera their PCIe card, then I can maybe pass that contact information on so he can talk to you about the details, and in that way put a True RAW tap on the camera so that full sensor data can be recorded to SSD on a computer.

He has a 2.5K sensor board already and has written the recording software to record from that sensor board, the combo of the 2.5K sensor board and PCIe interface is about maybe $500, so maybe doing True RAW from a GH1 or HDSLR would be about the same cost.

The results from his 2.5K sensor board would be similar maybe to the Vimeo videos I made using the KineRAW-S8p (tm) cameras but his OLPF and IR-cut filters are different so they would not be an exact match, I already have support for both OptimaCine.com (sm) and KineRAW.com (sm) cameras in my free de-Bayer software that is up on my web site for free download now.

If you have any questions or think you can help with such a hack, email me and let me know, please put 'GH1 RAW hack' in the email subject line, thanks. My address is: tempnulbox (at) yahoo (dot) com

Anyone with camera circuit skills that wants to help with what could turn out to be an important advance in digital movie capture can contact James at OptimaCine.com (tm) to share what information he might have about how to tap the sensor signals.

Updates:

1) James at OptimaCine.com (sm) finally put an email contact on his web page. He's looking into various options for revising his camera design as I understand things.

2) Kinefinity.com (sm) is finishing initial testing of their two new KineRAW-S35 (tm) prototypes, I have been processing some test DNG for calibration of monitoring tables to use in the cameras so shooting of test footage can start before too long. As I understand things, they would get back to the KineRAW-S8 (tm) re-design after the S35 goes on sale in China.

I've got my DI system processing shots and the editing and sound mixing seem to function so far, so it could be possible to finish a feature film, if anyone finds an issue they should let me know. My de-Bayer program has a general configuration so other cameras not listed in the camera type menu, such as Aaton (tm)'s 4K camera can probably work by selecting the generic RAW or DNG camera type.