Hello all, my question is about The AJA Kona 2 card and Final Cut Pro HD. The AJA website said that the Kona 2 card can convert raw 720*1280 into DVCPRO-HD using HD-SDI. My question is this, is there a way to convert the signal from one of the inexpensive cmos cameras(silicon imaging 1300 for example) into HD-SDI. I know that DVCPRO-HD is not the ideal system for feature film work(8 bit, 960*720 after bayer filter)but i am just a poor filmaker trying to get my film made. I am not trying to reinvent the wheel. Also, is there any way to manipulate the signal before compression(white balance, basic color correction). If this idea is entirely stupid and there is a much better solution please let me know. Any posts that point me in the right direction would be greatly appreciated.

Steve Floyd

I don't know of a "system" yet....I am working on stuff with lossless or near-lossless codecs but nothing yet...keep our fingers crossed

Say guys, a friend of mine just emailed me an announcement of a relatively new codec from apple called the "H.264/AVC". Is this something we could use?

http://www.apple.com/macosx/tiger/h264.html

Claims to be some greatly sophistocated codec that can do scaleable HD. I don't know really what to look for that much, but one of you guys probably does. Check it out and tell us what you think

H264 is more lossy than Divx or Xvid.It is meanto for extremely low bitrate video, head to head with Windows media 9, some peolple say it compresses more....
So I don't think it is suitable for capture.IMHO.

<<<-- Originally posted by Steve Nordhauser : Wayne, I think you are mixing metaphors. 10 gigabit is rapidly becoming real. The support structure (switches, cards, etc) will take a little while to become affordable (out of the backbone and into the office network). This is just a transmission medium, like camera link and HD-SDI. Of course you need a PCI bus to keep up with this. 1Gb ethernet can move data at about 100MB/sec.

That is the full bus bandwidth of PCI-32. I'm still a camera link fan for cost since it doesn't add too much to the camera and our bundles are $500 for capture at 32 bits and probably $1K at 64/66. HD-SDI requires the video processing up front. Certainly dual GigE would give you twice the bandwidth into a 64 bit machine, but why not camera link - you won't be straining it in the least.

FGPAs are just hardware that is reconfigurable. The difficulty is that although it looks like programming, it is hardware design. As Scott has pointed out, there are some public domain or licensable solutions. I looked at the clearspeed website. They have a 64 parallel processor CPU. The big thing with parallel processors is that you need to parallel-ize the application to gain any benefit. Since they say you can just program away in C, they must be solving that problem during compile. The SDK was $25K with $1K/chip in volume. -->>>

No, I'm not mixing metaphores, I know what I'm saying, even if I don't indicate that at times;). I know you mentioned GBE FPGA, so naturally a 10GBE FPGA might be possible. The Russain FPGA design looks almost credit card sized. I know if a MB had 10GBR or GBE that we can dump the capture card cost, if the camera also has GBE or 10 GBE. I know that these MB ports can bypass the PCI buss, or we could use a PCI-E or 66Mhz/64bit PCI in future. If HDMI is used then simular saving might be possible, and you never know the next version might even be 10GB's. Over the short distance even DVI to DVI might be an option. Just looking at cost reduction. You could also interface Clearspeed to GBE. Anybody can have the option to spend the money and have HD-SDI, Boxe, and Cineform, but I am interested in the entry point cost aswell (that is why USB 2.0 would have also been good, but it is not upto realtime processing requirements). So everything from the handheld, single drive, nano-itx 720p version to the 4 drive SHD version canbe done at minimal or maxi costs. 2 GBE (now available) on MB is enough for SHD bayer.

I am surprised at that pricing from clearspeed. This leads me to believe it maybe possible that they may have done a small run of 10K-100K chips, and are trying to pay expenses off those chips until they have mass market buyers (100K+), instead of doing a loss leader. Nothing wrong with that, hardware is very expensive and potentialy very low margin, and it is a very high performance product, not good for us though, but if they can get into a mass market product with runs at least in the millions, I think it should be available a lot cheaper.

Thanks

Wayne.

<<<-- Originally posted by Steve Floyd : Hello all, my question is about The AJA Kona 2 card and Final Cut Pro HD. The AJA website said that the Kona 2 card can convert raw 720*1280 into DVCPRO-HD using HD-SDI. My question is this, is there a way to convert the signal from one of the inexpensive cmos cameras(silicon imaging 1300 for example) into HD-SDI. I know that DVCPRO-HD is not the ideal system for feature film work(8 bit, 960*720 after bayer filter)but i am just a poor filmaker trying to get my film made. I am not trying to reinvent the wheel. Also, is there any way to manipulate the signal before compression(white balance, basic color correction). If this idea is entirely stupid and there is a much better solution please let me know. Any posts that point me in the right direction would be greatly appreciated.

Steve Floyd -->>>

Hi Steve, I'm a bit confused, I might have been missing something. What about installing a HD-SDI card aswell, recording the bayer footage through camera link, and then trancoding and transmitting it by HD-SDI, it should even be able to be done realtime (though I would ask the Rob's when that will be possible).

Thanks

Wayne.

Wayne Morellini wrote:
What about installing a HD-SDI card aswell, recording the bayer footage through camera link, and then trancoding and transmitting it by HD-SDI, it should even be able to be done realtime (though I would ask the Rob's when that will be possible).I'm sure it's possible, but since I have very little interest in doing it, someone else would have to pick up that part of the project (or donate equipment and $$$ :-).

Steve Floyd: If you're just trying to get your footage into DVCPRO-HD, is it really necessary to go through HD-SDI? I think it may be possible for our "Convert" software to use any QuickTime codec as its final target, meaning that you could get your DVCPRO-HD footage without dealing with HD-SDI at all. Now, the solution we're currently working on will not be real-time and will be a big hard-drive space hog* (though you can delete the raw files after compression DVCPRO-HD if you like).

(Of course, keep in mind that I am not yet an expert in encoding into QuickTime. I hope to be soon.)

* Hogs in space?

Sorry, I wasn't suggesting that, I was thinking of using two existing third party programs running in the background that take your output then transcoded it, and pass it to a transmitting program. I think it is a obviouse solutiuon that should be out there and doesn't require us to copy it. Who ever wants to spend money on HD_SDI should be able to find something like this. I would think that many HDSDI cards had transmission progams, if not some transcoders that could take one of the formats Rob's program outputs (otherwise somebody undoubtibly does). If it is not included with the card it should only require some technical googling to locate an suitable transcoder, or asking the cards support department might help even more.

Hm
a bit sarkastic, have a look at: http://www.dynebolic.org/
it is a live CD you can nest on a pc, open Mosix What does ist do for us ? Run on two PC it will build easy, dump easy a cluster. It has Cinarella just ready to start, Jahshak, Gimp, it is the only LINUX out there for video or streaming music. I've been far too long working for Intel, but only realtime. So we used Sun, embedded and strange hardware but all documents were written with Framemaker or Quark. look to any 200 or more pages Microsoft documentation, never written with Word !!

Will sayCinarell is not bad at all, I do use KNOPPIX, the easy way to get a full Debian not tested, unstable - rocksolid, as rocksolid as my beloved bi-pro SGI Octane from 1999. So Jahshasa is not Combustion but free, Cinarella can do HD even know by the big's in film biz.

As Linux is in set-top boxes, Cellphones, etc at all is GNU the Camear board coul run it as well, as the code from doo google some video for Linux is free, not Cinarell the way would be with Epix to have a Cameralink oot and an Gig Ether in. For me the only doing the job today.

Oh a bit more sorry Ther is DV out and for consumer ther will be DV tape or maybe blueray. Interframe compression but never ever wireless or Gig ether. why.

Me strated music with five, break jump in the recording biz with 16 part time. We did Charles Mingus and much more like ECM in Munich but from a small village in the black forest. MCM gone far ago. It was easy, we bought an old famous mixing desk, tube gear nobody wanted anymore, 1972, and so on it has been a great time.

Today the entry level for live recording is very expensive, and look to http://www.dvinfo.net/conf/showthread.php?s=&threadid=34533 it's like all the time with music, no answer only how to mic this, what to take and is X realy better than y. Why writing this, there is a lot of software out, running most on Windows, RME card are fantastic, but Windows is no way to have it on the road, ask the DOD. Army is the reason that somebody as SGI is still alive.

What is my love with film? Well ist's my Eclair modded for S16 with an Acl 2 motor running up to 75 fps. Angenieux Paris f 10-150, 1:2,8 and converted from a russian Kinor F-6 mm wide angel. 1:1.8.
I do use film that pasted the date and know somebody who precesses DIY. I did it with color and Dia all th time DIY. Than I do scan it with a scan unit out af a Pentacon Scan cam on an old huge cutting desk, producing zillions of tiffs. scropping the image and it looks great. It's not cheap, takes lot of disk space and so on. But I do have no Pixel, no bayer no artifacts nothing, it only takes to scan a real a day or even more and has to be dust free. I do have the film allways as a eternal backup, well fire or moisture can eat it away.

To Wayne you had the idea with the 2 CMOS setup on in the place of the penta prism and one in the film plane. So why not use 4 all the setup in some high tech plastic, carbon or so sealed, glued together, most airplanes are "glued" together nowadays. Why so crazy, one Altasens is even not the S16 format The Foveon with the low resolution can group pixels together, thats not bad, he is 3 layer, and four of these would give a real nice DOF could be $$ but ... reolution ? but low light and so on, no bayer 3 Cmos in one chip.

Think of it, on a 35mm camera ther is, ok shutter speed no way to have another setup no gamma no look no no no. Why the hell to have it on our baby, the viewfinder issue is not easy and religion. All the rest is lunatic, go out and look to a S16 or 35mm shooting. That's Film and needs a crew, that's not video, and now we have the force that drives us mad, cost of production. You can do 35mm or better S16 with team of two and even some ambient sound, the rest is post roduction and why change this. A lot of indie, documentation and even drame was shot this way. The price of Kreines cam drives me mad that's a fact. What is the issue with me? Well I do need to adjust speed, to have exposure shutter as wi th an Eclair, Aaton , Arri, toged rid of noisy motor and cumbersum expensive film, but have S16 DOF at least, nicer would be nera 35mm DOF. Relolution could even be 2x blown up in post, why not but no Argus, ground glass or so, as it takes light away and there is never too much light in film

nerci

Ronald: you seem to like going in a totally different direction, which
is fine, but also quite costly. The reason most stuff is developed
on Windows is the following:

1. most programmers here work in the Windows environment
2. not all cameralink boards (or gigabit ethernet) have drivers for Linux/Unix
3. the goal was to setup a system that could easily be build by someone with a bit of knowledge. Most people in the video industry do NOT have Linux/Unix/Cinelerra experience
4. I have yet to see anyone on this board who uses Cinelerra in a serious fashion (some people are kinda looking at it)

The question is not which can do HD. Sony Vegas (NLE) can do HD
and I'd much rather use that product for a whole bunch of reasons.
The issue with editing is with the higher bitdepths. Normal video
is 8 bits per channel (whether it is RGB or YUV), we are talking
about a 10 or 12 bits signal which I doubt Cinelerra supports
(I couldn't find any sort of specifications for the product).

Personally I don't care if the DoD doesn't want to run Windows,
I do personally. It is pretty easy to have "Windows on the road"
(as you say), people do it all the time with a laptop. Power is no
real concern with good equipment and good batteries.

Ofcourse you are free to develop solutions for Linux or any other
OS as you see fit, Ronald. For now at least our time is focussing
on Windows. I believe Obin was working on a Linux version and
at the moment it is unsure how the Drake camera is working...

Thanks a lot and ok laptops are fine for any use, have my 5Megpix still cam conected, voila, but closed and some wifi card, a firewire disk not running very long, They are closed boxes. A small pc in a tin-can with a decend keybord, a spacemouse and a flatsreen, I do have in my car and it's much better as an laptop.
Dualboot Linux, Windows as I can drag each Linux tiff, jpeg or avi on the windows partition voila two worlds and I'm happy.
Using both it's great, beware there is not yet a real Linux virus out, quite each linux disk is set up personally flavoured, no stupid registry and no stupig windows directory. As all is GNU and most is C where is there the problem ? Cinarella is, as I do know 10 bit maybe will be xx next year.

Tell me FILM is not only bit's, same as Music-16 bit 24 bit 96kz or what, can you hear the difference ? Hifi nuts are going tube, 4 watt amps with ideas from 1930, they don't hear this.
An electrostatic headphone can do this http://www.headwize.com/ but does not look so sexy as huge speakers or $$ small ones. it's all psychoaccustic, Film is a bit tricky as the hyman eye is hard to be fooled so it is resolution, DOF, inspiration, light, inspiration, hard work AND sound. If it is Vegas or what I don't care. I dont need tons of 3D animation, im telling a history, a strange one, a love-history, an animal-documentation, what ever, it's allways a love history. If it is xxx bit who cares it has to be projected in cinema format, if it does its okay on DVD, not vice versa.
ronald

Rob Lohman wrote:
...10 or 12 bits signal which I doubt Cinelerra supportsCinelerra supports 10-bit 4:4:4 uncompressed via QuickTime for Linux.

See this link (http://heroinewarrior.com/cinelerra_shots.php3) and scroll (or search) down to "Comparison of the 8 bit and 10 bit YUV codecs."

ok
I do like Cinarella , I do like Linux, I do like Windows to dig in the www, Copernic agent pro, I do like to have email on linux, so far no virus, no registry and no stupid disp layout all over the world the same vulnerable windows folder and so on. If windows would not tell you YOU have unused icons may I clean them and in an hassle you hit retun key, and so on, it would be a nice OS but why does it need so much space on a disk. ??

LOL Cinarella is free, it comes with Dynabolic no instalation nothing, the MOSIX can cluster several PC voila you have a render farm indie-style easy, cheapo. The camera is on issue, lighting, and all the stuff needed for film, and even your actors are your friend logistics and catering tranportation etc.

Keep the cost on NLE down, invest in the Film !!

Hello,

I posted some links to Cinelerra in times past. I think it will capture 12bit from memory.

I think what Ron has said has merit and canbe done quiet cheaply (as long as you have a cheap SDI camera). If we select and work out one of two known boards and a set of devices, with all the drivers/linux worked out on a disk image, all the user has to do is buy this hardware and restore the image to it. Cheap and simple, if we had done that we would have been up and running ages ago. But the problem is who has a HDSDI dual link camera cheap enough? Still, with a simple capture from Gigethernet in 4:4:4 raw bayer/3 chip modification to Cinerlerra that could have been done to, but as you said who wants to capture from a full editor program.

<<<-- Originally posted by Rob Lohman : Ronald: you seem to like going in a totally different direction, which
is fine, but also quite costly. The reason most stuff is developed
on Windows is the following:-->>>

By the sound of Obin's capture problems, it sounds like he's hit the same snag I talked to Rob about near the begining. Don't know how long it will take for his programmers to work it out, the only other solution is too change hardware, probably to a faster system. I'm confident that wecan probably capture 720p bayer to even a 300Mhz system (preferably not PC though), even with compression, now that will blow a few minds, but if Ron has done extensive machine code realtime embedded programming he should be able to do something like that. When you look at it that Meneutos I posted on the other thread might be perfect to do that on the PC. The guy that did that (who is putting in a C library for people that want to port things like Cinerala (ahhg, how do you spell that, why didn't they just call it Cineralla, and go in partnership with Disney). I read a article where the guy that did it was asked about the speed advantages over some other c based OS (Linux or windows maybe). He said somethign about when they replaced certain parts of Linux with machine coade they saw a 40-60% (don't rember) speed increase. So imagine what canbe achieved by a full machine code OS, and machine code capture app, and program by a very skilled programmer that knows how to optimise for every chipset and subsystem in a chipset ;) Now all the capture problems start disappearing as that big processor sudenlly can do 100%+ more.

Ronald:
There is support out there for Linux. I know Epix and Active Silicon have Linux SDKs (I believe the Epix GUI is in beta) and our gigabit ethernet has a Linux SDK.
Gigabit:
The supported platforms for such currently are RedHat 9
(recommended) and SuSE 8.2 (recently added to the list). In fact we do have customers using other linux distributions, but we are limiting support to the 2.4.x kernels, since we still need to create custom drivers. The API for Windows and Linux is actually the same. So any program written to work with our SDK in Windows should work much the same way in
linux.

So, are you saying that Rob's capture program could port straight accroos, that's interesting. Thanks.

Wayne Morellini wrote:
So, are you saying that Rob's capture program could port straight acrossWell, most of it is portable, but the UI uses DirectX.

With all due respect to everyone, why does it really matter (at
least at this point in time) what OS is on the camera? It is nice
that Ronald is so (obviously) fond of Linux and I have a bias
towards Windows. It all boils down to two things:

1. the camera and the people who are programming for that

2. the rest of the processing chain

Now the first part (in the case of obscuracam) is at the moment
being done by Rob S. with a bit of support from yours truly and
for now is being developed for Windows because that is what
we can easily work with. In my eyes it does not matter much
which OS is being used at this stage because if all is done the
END USER WILL NEVER SEE IT! Since this is A CAMERA you don't
hook it up to the internet or whatever and therefore you don't
have to worry about things like virusses as well (which Ronald
seems to worry about).

Now the second part consists of the (what we call) "convert"
application (which is going to be opensource) and whatever
anyone wants to do after that (ie, editing). If someone wants
to take the convert application source and port that over to
a Unix version then by all means do so. If they then want to
EDIT this footage with Cinelerra then be my guest. In this PHASE
is where you actually start to work with your footage and I
can very much imagine people working on Windows, Mac OS X
or Linux.

So to get back to the main issue, I'd much rather have a working
camera as soon as possible then trying to work out whether it
should run under Linux or Windows. You can always switch to
another platform (yes, it would involve some work, but not nearly
as much as the initial development process) when the whole
process is working and you have camera's you can actually do
some shooting with.

Ronald: you will definitely see the difference in 10 or 12 bit video
because this will give you far greater dynamic range in your image
(the eye can see far greater dynamic ranges than is currently
possible with 8 bits). It is not comparable to the increase in audio
you mentioned.

Also, just to tie into your "(unused) space issue": the message is
easily deactivated (I don't get that message, nor the message my
drives are running low nor does it have customized menus where
it hides stuff not used, it's all settings) and I don't care if Windows
requires 1 GB or so to install, there is a harddisk anyway.

Now the next question is not to bash or something, but I'm
wondering something: does Linux support things like "standby"
or "hibernation"?

I believe latter editions do.

Does the OS matter? If you were talking about other OS's than Linux and Xp then I would say yes, much better performance and reliability. The other factor is that you can use it for other tasks and editing with the right OS. You wanted embedded XP to get the OS off the hard drive yourself previously. We started to save money, and in reality, and along simular theme to our project, Linux with Cineralla offers something significantly cheaper than Windows and Premier etc. But if it is hidden, we don't need Windows or Linux really at all, we could use Toas and get even better perfomance, or a native Machine code OS/or developement system. But at the moment we just need to get it working then worry about it after that. But basically if we restrict hardware chioce to a few good MB, HDD's etc, we don't need Windows OS, byut will have to update everytime choosen MB and HDD go out of production (as OS does not contain hardware abstraction, we do that). Now drivers for Linux, there are a few attempt and even universal driver format project, but you also, Rob S, have one that allows Linux to use standard Windows drivers, and another that allows you to use Direct X on Linux ;)

Why should an os do that ?
to start takes time so what comes in, Cameralink or Gig E could be lost, fact is in realtime where I do come from a system is up running all the time
I have just done a post in the Obin thread maybe a bit strange but that's my thinking. worked about 16 years beside ABS on strange thingsnthe non DOD like 5 axis machine control working as fast as a pice of steel can be moved araound and so on. Systems they run 24h and fail if a hardware fail, that's not Windows and not Linux, fun for me is a realtime OS and playing with the Lego brick plus two piggy bords, so it moves the lego cam around and sends pic wireless to the host comouter. the computer compares the pics with his 3d invetury and knows the position of the brick. If someting changes he sends a new map to the brick a bit like cruis missiles do LOL.
So my son 11 years leanrs to do programming

I do like Linux, Dynabolic for instant as it is open, all Debian is open, Gentoo is open, just build what you need, no drivers sitting in memory idling thats not bad Hibernation is for laptops well an application can do this why not in linux should be out in www I'm sure

Wayne: that would be indeed a next stop, since we also spoke
about FPGA's and such. I'm not saying Win is the only way to go,
but let's get something working first is what I'm saying.

Again, I think (you as well Wayne with this line: "the other factor is
that you can use it for other tasks and editing with the right OS".)
everyone is confusing a view things. The PC/computer/chips
(whatever) inside the camera are not going (at least it really
should not) to be used for editing. You have a small system in
there to do one thing and one thing only: record (reliably). You
then either transfer this footage over to your edit suite or copy it
of the harddisk(s) directly.

Now, ofcourse this second stage (copying/transferring/processing
the footage and then edit it or whatever you want to do with it)
should be done on a "normal" computer and that can be any
platform that is supported. For now that is Windows, but that can
much easier be ported to other systems!

Ronald: yes, we would like an onboard realtime system with
something like an FPGA as well, but that is just beyond the scope
since we have no-one here that can build such a system. This is
*NOT* easy stuff! Windows could hibernate and would start
pretty fast as well. Personally I don't care with startup times since
these are clearly not run and gun camera's, but camera's for some
serious film shooting work.

As said above, let's get it all working good first and then see if
we can finetune or port it to better suited system. Unless
someone knows an excellent realtime system's designer who
has the time and expertice to do such a project...
I was talking about the OS *ON* the camera which in my opinion
should only be used for shooting.

I'm not sure why comparisons between DOD and now lego blocks
are being made. They either have much, much more money and
resources than us to design whatever they want or do not have
enough power (the bricks). If it where easy these systems would
be all around us already!

No Rob, I am agreeing with you, get the camera working first (as I said before). But Origionally the discussion was to use the camera for editing too, in field this would be useful for ENG and doco work (as well as some indie cin) and I have kept on this. The piont is that to support this feature you only need a different boot sequence and extra software on the system drive. Same camera, to make into computer hook in usb hub (with keyboard/Mouse/etc) montior and external/rack harddrive, three connectors off mainboard. So when you finish shooting go to your tent open up custom case (cheap foldout modified airport luggage) with keyboard etc inside and plugin, good simple and cheap. You don't have to do a complete edit on the spot, but maybe figure a few things out, scenes and sequences (scapping useless stuff) and day by day. So don't worry I'm sure I can do this myself ;)

Ron:

I think a couple of people volunteered to do FPGA before, but what I think Rob is also meaning ;) is that any Voluntreers would be welcome ??

Wayne: dual boot to another OS might be interesting indeed.
Would probably raise some eyebrows, you plugging a TFT Screen,
keyboard, mouse and power supply in your camera on your hotel
room <g>

Thinking in a purely speculative fashion, how might one go about making a camera that simply dumps data out to a drive - say a firewire 800. The camera would have no preview, no monitor, nothing but camera and disk.

There may be a way to get a drive to have an button that has two settings: write the data that is coming through/don't write the data that's coming through.

I shall elaborate:

I was looking at the capdiv hard disk recorder at http://lairdtelemedia.com/ amongst others and was thinking that perhaps such a thing would be useful for the uncompressed dvx 100 filmstream mod and if it could be somehow used with sufficiently fast disks/with several disks.

you may be able to solve some of Obin's problems with simultaneous preview and record by hooking up a pc for preview and camera controls (shutter, frame rate, gain) and recording via a second camera output/split signal direct to disk.

just a thought.

i'll send a mail to the capdiv people and see what they say to recording different formats on their device. also, some googling is in order.

It can be quiet small (as discussed in the other thrad), but you loose the PC in camera advantages mentioned above, plus you also loose the ability to plugin whatever prefered PC codec you might want, as all has to be built in and reprogrammed. What you need is to get fast enough embedded controller with Firewire800 (or sata etc), camera interface, and whatever orher conrtol buttons you want, for preview you will need display output. Now you need to get realtime embeeded developement system to program. Then figure out the external control electronics, and power supply/battery electonics and case. Program it then hopefully you will have working system in 6 months (if you have really programing, few are, in a month). You will need moire than one button to control camera setup for different lighting conditions, preview is the best I think. But good idea I have seen it before, but it was expanded.

Mmm, so it's hard then.

With Juan's dvx mod it could be a useful thing, since you wouldn't be using off camera controls (so far as I understand it). However, I was under the impression that his thing was FW800, and not USB 2.

As for something like Obin's camera, I saw the posts outlining how one could use two computers for capture and control. If you could make the first a simple on/off drive then it might be simpler and cheaper.

Perhaps it is possible to modify a firestream or a capdiv to write any old data, perhaps these companies might be willing to release products for raw data. perhaps perhaps.

Maybe it is not so hard as you think, as long as you have the abilities, certainly not as easy or flexible as the PC solution.

I don't reply to everything, as it would be a bit dissapionting, but the dual motherbaord technique will add a whole new level of headaches and complexity. Faster processor is probably better.

Yes you could do that, but most of those commercial to disk solutions go for high end prices, and would probably cost more than the complete PC capture system. But if you ghave a low price manufacturer in mind you could ask them about it.

No, no manufacturer in mind. Just thinking out loud. A little research and I'll see if this can be a cost-effective recording solution.

My first post here, but I have been following these fascinating threads for a while.

I have been looking around trying to find information on software and came across a standard called IIDC v1.3 (DCAM v1.3) which is part of the 1394a (Firewire) protocol to communicate with digital cameras over FW - at the most basic level, the sort of thing a FW webcam is based on I guess.

I thought it was interesting as some of these cameras are using 1394b fiber optic connections, which is both high speed and can extend over very long distances. An some have incredibly high quality outputs, although they are pricey.

Anyway, it seems there are masses of cameras which support this DCAM v1.3 standard, mostly being used for astrology and scientific purposes. I found this site which lists all sorts of cameras, which might be interesting to some here:

1394 IIDC Cameras (http://www.tele.ucl.ac.be/PEOPLE/DOUXCHAMPS/ieee1394/cameras/)

And also some simple Mac OS X software built on this standard. However it is not really designed for what we all want here, it may be of interest to those developing their own apps, it is supposed to support IIDC conforming cameras. It costs around $50:

Astro IIDC Mac Software (http://www.outcastsoft.com/ASCASTROIIDC.html)

I emailed the developer with a few questions and here was his part of his reply:

------------------------------------------------------
"We have 3 main bayer algorithms 2x2, 3x3 and 5x5 kernel methods to handle bayer 8, bayer 12 and bayer 16 bit input formats, support the 4 RGB variants (RGGB, GBRG ) and can deliver RGB24, ARGB32 and RGB48 bit formats, which is a total of 108 Bayer variants. The 2x2 and 3x3 methods are real time and the 5x5 one is designed for photographic final rendering.

The app converts the bayer video for display in real time. When recording as QuickTime movies, the bayer video is saved in the movie and is played using our Bayer Codec. We do not currently offer the Bayer Codec outside of the Astro IIDC application.

We do not support "external algorithms" and have no plans on doing it.

We do offer our IIDC API and SDK, but that starts at $1000 USD and goes up from their. It's intended for developers so they can build their own applications without using QuickTime and is not for end users but it would extract the raw bayer frames and allow you to do whatever you want with them via your own "custom" algorithms."
------------------------------------------------------

Seeing as 1394a (b on Mac) is a ubiquitous standard and is connectable to the computer of choice without any significant (if any) cost, how difficult would it be to adapt these cameras people here are looking at into FW based systems?

Is the bandwidth the major concern for using FW as opposed to CameraLink? Would 1394b make enough of a difference?

I am also interested by the idea of having a camera which can send uncompressed data to an app such as Final Cut Pro and then be transcoded on the fly to Quicktime codecs like Apple 10bit uncompressed, DVCPRO HD, or uncompressed HD.

Being an editor, I am all too aware of the issues of storage and although I love the idea of a pure 4:4:4 RGB recording for some projects, I also think a camera which could feed an uncompressed signal through FW to FCP and then be transcoder on the fly to a manageable but high quality codec would be hugely popular with the post production community as well.

I know these designs are really about the acquisition and not so much the editing, but the DVCPRO HD codec is a massive hit with the post community because of its good quality and very low data rate.

I know Blackmagic Design (Decklink, HD-Link etc) are developing a 4:4:4 RGB Quicktime Codec and they are some of the best in the industry at doing this. Their Dual Link Decklink HD PRO card could handle the capture from HD-SDI, I am not sure if it could be utilized as an encoding card for data delivered over another form of cable. Contact Grant Petty or Luke Maslen at Blackmagic Design, they are a very responsive company and I am sure will give you some useful feedback.

How difficult/expensive would it be to take a Dual HD-SDI feed off the AD converter of the camera?

Anyway, I wish you all lots of luck, I am glued to these discussion now, so can't wait to see where you go with your designs.

Regards
Mark Burton

Okay,

I've been on these threads for about a year now, and when I first came on I remember vividly about all the stuff that was coming out from Summix and SI in "just a few months" that was basically going to be a studio signal quality camera, only in box format.

I Keep hearing and hearing about when the "real deal" is coming out. First it was mid summer, then september, then October, then November . . . P.S. November is almost up.

Are these 1080p, global shutter, 4:2:2 color space, c-mount lens fixture, 100 MHz, 64 bit, 24 fps+, $3000 cameras really going to come out any time soon, or is this going to take another year. I'm asking because I'm looking to shoot a feature in late Spring that i'm taking very seriously, with semi-name actors involved, and I need to bank on what's in front of me, not what might or might not come out soon.

I'm starting to think that by the time we actually get this stuff up and running, there will be commercial cameras with near the same quality and price from Sony or Panasonic just around the corner, so why bother?

I can't remember who I was talking to on the thread, but at one point I mentioned it's far better to spend a year or two working a mean job, and build the capital for reliable commercial equipment (that will drop in price over the time you spent working) than to spend a year or two working on something that in the end might give us all mega functionality head-aches during production . . . and have no money left for your project to boot.

The only reason I bring this up is because it has been a year already, and I don't think I can wait another one before shooting something serious. I also don't want to wait another year for a camera that cries wolf.

Maybe I'm missing some of the stuff that has actually come out? Or am I right that none of the cameras we've really been looking for from SI and Summix have really come to light?

Someone please fill me in as to what's going on.

I love you guys.

Thanks

The delay was allways sensors (and capture software). The tested sensors had problems, so Sumix and SI decided to go for quality Altasens, then Altasens had trouble manufacturing that will add around six motnhs. Given the Christmas periode, we probably will see something selling Februray, or so. We may see anouncements in December or January, but I expect the Christmass break (followed by a holiday in some companies) will make it hard to crankup production to Februray).

As far as price goes, I think Sumix is the only company I have heard of releasing a Altasens camera below $3000. I think that after Sumix decided to go for Altasens they put back their schedule to end of the year anyway.

Unfortunately these things do take time, and if you got all the right parts (including capture software) it can be done in a month (plus another 6 weeks+ for production preperation). If you look at what Rai recently said about the Drake system, is that they are still deciding on bits and peices, I forget where ever this was for marketability or technical changes for production, but I think it would be both. This is fairly normal.

Of the new commercial cameras, truth is there has been huge delays there too. I understand that there was new Sharp single chip HDV cameras at the beginning of this year (I think even a new HDV camera last year). The Sony is finally out and may have very good optical quality compared to Fillfactor Ibis and the Micron Sensor used in the 1.3Mp SI. But the truth is that they record HDV1 and you loose a lot. The minium that you need to "compete" with us is the HDV2/Blueray disc format (still not as good, but good enough for many things). So yes, we may get a 3 chip Altasens JVC Eng camera with HDV2 (don't know for sure) for around $20K. But being an Akltasens we might only see it a few months before we get ours.

Well, what you will get saving up for a year or two, will probably not be Raw from Sony/Pana etc, or as good, or as cheap. But look at it this way, it hasn't really cost you (only a few of us) much yet. So you can use the development time on a mean job to saveup and buy the best camera and production equipment. Actually I can say in a couple of years time it might be possible to do a camera system like ours for $500-1000, where as many of the HDV2 "competitors" might be still more than $10K (maybe somebody will come to $5K).

And yesa, I am very very very dissapionted that it is taking so long. Actually how good was the older 1.3MP Altasens, anybody? Is it suitable for a cheap 720p camera instead of the existing sensors?

My actual worry is that in the end it might prove as good, and maybe cheaper, to convert an existing camera to raw. I have heard of cameras that can do that, and while I discount that because the only ones I know are SD, the footage from Juan's DVX100 looks great.

Ohh yes, I think we started around 8-10 months ago.

Hang in there Laurence.

Thanks for the post, Mark, it is probably better to repost it to my technical thread (or Obins 10-bit thread) as much of the discussion has moved from here.

Yes, 800, 1600, or 3200 Firewire would make great difference, everything is still on the table though only Gige is talked about at a moment.

About transcoding to high quality codec, they are planning on adding this functionality in future. The cineform codec people have also got a suitable high quality codec too.

HDSDI is more complex (and limited) and was rejected as a FPGA design some time ago.

Thanks Wayne,

Makes more sense now. Hey, can you remember what website/company it was that makes the c-mount to 35mm lens adapters?

Thanks!

Angenuix or something like that. I think I posted a link in the technical thread a month or so ago (otherwise maybe the ten bit thread). Pretty expensive I believe.

Wayne.

Hey, can you remember what website/company it was that makes the c-mount to 35mm lens adapters?If you are talking about physical adapters (no optics), B&H photo/video carries some (http://www.bhphotovideo.com/), such as a C-mount body to F-mount (Nikon) lens. (http://www.bhphotovideo.com/bnh/controller/home?O=productlist&A=details&Q=&sku=77558&is=REG)

What do you guys think of this box camera that supposedly "was designed for digital cinema/tv"?

Maybe expensive? Maybe not?

Input, please.

http://www.isgchips.com/Templates/t_quadhdtv.htm

very expensive
and well known
and you need
ton\s of disc\s to hold the data

Sure the Spielbergs can buy anything they want to get results. At the other end are the people still messing with analog camcorders trying film making for the first time. We are doing an elegant dance here trying to reach for lofty goals with limited resources - a fiscal ballet.

At least that is the crap I try to believe when my pockets a full of lint and I am coveting a new tool.

Steve,

“A Fiscal ballet” that is the best nutshell description I have heard to describe the endeavour.

Also, how is the SI1920HD coming along?

John, the technical school I went to said I would have no use for the high verbal SAT score that I had. Now you know its real value in engineering.
New batch of sensors due early January. We will turn cameras around within 1 week of receiving them. We have cameras scattered with a bunch of software developers, interface integrators.

Dear Steve
does it read with Altasens ?
and if which one?
and if what output?
and if which price about

so many if's so sorry
but if

Ronald, take a deep breathe, relax.
Yes, the 3560. camera link and gigabit ethernet. Email me privately for purchase information.

Steve, I understand there are older Alatsens sensors allready out, are they cheaper and are they suitable for a cheap camera?

Wayne.

Wayne,
There are two sensors shipping that are interesting to 1080 people. First is an older 30Hz part. We aren't messing with that because it will be stuck in the rolling shutter artifact problems - if you want to save money go to our SI-3300 for less than half the price. Next is the currently shipping 3560. They have gone through a number of mask iterations and the current one is almost there. We have built a number of cameras with them and they are nice. We just don't want to release a bunch of "orphans" - cameras that may not handle firmware upgrades, may not perform the same - so we are not shipping the current sensor in volume.

The next version of the 3560 is due "soon".
Steve

So they don't have a 720p part, and they aren't going to keep the older part as a very cheap cousin for the low end of the market. Thats all I needed to hear. Thanks Steve.

Wayne.

Does anyone have a link to some basic technical info on building a camera from scratch? Just the general info on how to get the picture onto the ccd properly (what types of condensor lenses are needed before the ccd element) as well as how the information from ccd is sent? All of the "how digital camera's work" tutorials have been slightly informative but far from detailed enough. I have some experience programming microprocessors so other than those two aspects, I have a good idea of how to do the rest.

More or less what I want to do is dump raw images individually onto a hard disk, and then put them together in post. So info on how to build a still camera would be just as useful.

Thanks,
Matt

Hi Matt

I don't know of one, but it is good to check sensor and camera manufacturers sites for information on sensor terms. I've listed the best information I have seen in some of the threads (try the Technical thread first and http://www.siliconimaging.com ).

Everybody has moved onto variouse camera projects, and some want to do the same as you want. Go to here for a list of threads:

http://www.dvinfo.net/conf/showthread.php?threadid=28781

The only other new thread is for the Drake camera:
http://www.dvinfo.net/conf/showthread.php?threadid=34339

What you want to do is very difficult, so we have decided to use pre-made camera heads (the bits with the sensor and interface) existing mini computers boards, and our own capture programs.

Now there are three mobs: Drake, the Rob's (one our moderator), and the Obin. Both Drake and Obin are close, Rob's are busy for the moment. We are looking at using cameras based on the Rockwell Altasens sensor, close enough to an A grade HD CMOS sensor. I think the only cmos sensors, that I know of, that offer anything extra are those that do hispeed video for slow motion effects (and there was somebody on here with one of those too). There is SHD sensors, and maybe better cmos HD (though I don't know of any) out there, but they may cost far more.


Camera makers: Sumix was the first to announce support for us, but they are going to be like March or April, Silicon Imaging are supplying now and soon with the Altasens.

The micron 1.3MP camera has problems and is not recommended for professional video without sensor affects, the fillfactory IBIS5 does not have these problems but is still debated about it's usefullness (though Drake uses a refined version), the Micron sensor for 1080 is much better, the Altasens alledgedly much better again.

Wayne.

Thanks for the info,

Actually what I want to do is quite different I think. More or less I want to split an image among several still SLR ccd's either using prisms, or by a timed synchronization of a moving mirror (or even by physically moving the ccd's into postion). Those sorts of ccd's would create super high defintion images...but unfortunatly can't take them at fast frame rates. To compensate for this I want to use many of them and have them shoot sequentially, then have software order the individual pictures from each. I'd hope to be able to use full frame ccd's for the dof as well. Unfortunatly, I really don't know where to start as far as aquiring and setting up the ccd's is concerned.

Thanks,
Matt

On the topic of video cameras as opposed to my crazy still idea...could cameras such as this be put to good cinema use?

http://www.rmassa.com/manu/pulnix.htm

Particularly, the TMC-1400...or the TMC 4000 if my alternating frame grab idea is possible. (It might be even easier using something like the TMC 4000...simply use a beam-splitting prism and cause the second camera to begin frame caputure 33ms (1/30 of a second) later.

Matt

Looked at those cameras and they appear to be quiet expensive compared to some of the prices we have been looking at around here. Best to check out the links to cameras on the web. I think Ronald has posted links to lists of hundreds of cameras on the technical thread, and I have posted links to the products database of the cameralink standards organisation, and supported cameras of the pixellink capture card company.

I also think Ronald might be interested in something like what your talking about, so it is probably best to post over at the technical thread.

Now on your idea, looks interesting, probably expensive. Every time you split you divide the amount of light, and I don't know what image faults that sort of prism introduces, as well as path length. Note, a lot of chip have rolling shutter, that causes moving object/images to tilt at normal shutters. If you speed up the shutter, to make it more like global shutter, mking the tilt almost unoticable, you loose the extra light gathering ability of a slow shutter. Other things to watch out for are that some cameras readout times are so slow they interfere too much with the next frame round and shorten integration time etc. Now you have all these different feeds coming in simultanously from different sensors, and you have to manage and buiffer them to record them in the right sequence. So you have a lag of a full frame readout before the disk can start recording. Instead, if each drive has enough bandwidth, you can use one file per sensor on each disk, as recording accross multiple files per disk will kill disk perforamance like a dodo because of seeking. The only other option is to interleave them in one file accross the raid, and I don't think you want to go there because of the timing accross multiple sensors. So the slow readout will cost more than normal. But having not thought about it maybe somebody else has a better idea to contribute.

I have recently suggested, on the main thread, that pixel shift on a 1080 3 chip camera would deliver between pseudo 4 and 9 times the resolution. But objectively we shouldn't expect much difference from a 6MP sensor (but a lot more light).

Wayne.