4:4:4 10bit single CMOS HD project

[Obin Olson]

cost - $11,000 ;)

[Obin Olson]

Ok I am fired up now!!

WHAT IF

We could build a microatx/ITX computer running LINUX and put it inside the camera housing? Would LINUX be as stable as we need?

Why not write a UI for this system with standard menus for a touch screen on the camera...this would use standard off-the-shelf equipment that we could buy online. What stops this from working ? We could have sata drives that are hot-swap. This is nothing more then taking the remote computer and building it inside the camera right?

look at this!

http://www.damnsmalllinux.org/

it could be loaded on a flash card. No need for a 3rd disk drive for the OS

[Wayne Morellini]

Hey, you wouldn't believe it, the guy that did that Bayer filter tutorial page, I think I might know him, I have one of his old Miminal Instruction Set Computer microprocessors here. I'm trying to contact him now, he is one very smart guy.

Wayne.

[Wayne Morellini]

<<<-- Originally posted by Obin Olson : Ok I am fired up now!!

WHAT IF

We could build a microatx/ITX computer running LINUX and put it inside the camera housing? Would LINUX be as stable as we need? -->>>

I haven't got to reading the last 40 or so posts yet, but yes, Linux would be m,ore stable than Windows.

I still suggest looking at the Toas intent/relate environments under linux, they are likely to be more efficent.

Oblin about the Shuttle PC, there are other low niose alternatives, and lower wattage P4's coming out. I drafted trhis before I got to the Shuttle site:

<<<-- Originally posted by Obin Olson :
OK I think I am going with a Shuttle computer system! check them out at : http://sys.us.shuttle.com/

It will cost me $900 for a shuttle, 2.8ghz p4 CPU, 512megs 400mhz ram, 2 7200rpm sata disk drives at 200GB each, a dual head graphics card and a 40gb OS disk drive..then I will use firewire to transfer all the footage from shuttle to video server after shoot..I am hoping to get 60fps 8bit on this system and 48fps 12bit all 1280x720p

if anyone has an idea of a much better system for size -speed - price please let me know soon!-->>>

I should have mentioned this in an earlier post. A lot of high speed systems produce fan niose, but there are some small systems that are nearly niosless. It looks like Shuttle has it, I don't remember which other systems there are but try looking up reviews, and news links to reveiws, in tomshardware.com, and anandtech.com. Nioseless, low niose are good search phrases, and their systems reveiw section. There are two types, quiet fans and large heatsinks with thermal liquid cooling etc. I also think there is also new low powered versions of the processors coming out soon (if they haven't arrived). They use half the power, probably upto 4 times less processor fan niose, or you might get a faster version. digit-life.com also has a good news section for struff like this.

Thanks

Wayne.

[Wayne Morellini]

About the reflected Microdisplay panels. There are many, with devices that can run over 180fps, to give true 60fps sequential colour (not sure but top speed might be over 300fps). Hopkins had a link page to many of the microdisplay products, I think. www.microdisplay.com was the only one I know of working on a non sequential colour LCD version (using broken reflection I think). They also claimed integration advantages like the Emagin.

OEL have a problem with uneven primary colour deteriation with age, and might need to be replaced every few years until worked out. Check out the halflife spec on the Emagin to see where ever it has the problem or not.

[Anders Holck Petersen]

<<<-- Originally posted by Obin Olson : cost - $11,000 ;) -->>>

Is that for the panel/controller or for the accuscene viewfinder?

[Rob Scott]

Jim Lafferty wrote:thanks for the wiki update -- it's a fun read so far

You're welcome! :-) Thanks for the encouragement.

Eliot Mack wrote:
I've been reworking the project Wiki

Thanks for taking the time to do that, Eliot!

I've updated my development blog, but I'll be traveling for a while, so I won't have any more updates until next week sometime.

[Wayne Morellini]

<<<-- Originally posted by Juan M. M. Fiebelkorn :
Sorry about my error saying '' without affecting image quality" I forgot to add ''too much''.
I guess I don't know what you think are the results of a lossy compression like JPEG2000 on an image.Anyway
-->>>--

Hi Juan, welcome.

I am one of the main proponets of lossless, but the different projects accross the different threads, are not exclusively lossless, I have advocated lossless for high end, high polish work, but also advocated lossy/near lossless for other work. The main problem with splitting the bayer pixel into sub channels and compressing them
seperately is that it is hard to gaurantee that the compressed pixels will still match up in each channel unless it is true lossless.

Rather than FPGA/s check out the clearspeed links I posted over at the viper thread, they should be much simpler and cheaper to implement, and probably faster. There are also links around here to the russian work that did FPGAs for camera comrpession, the FPGA files were also open, I think he had links.

If we go for clearspeed/FPGAS eventually we might as well go for highest quality compression than speed, but in the short term quality high speed. The situation is only temporary as computers will get fast enough to handle it. So we should keep it open and universal in nteh long run so we can adopt better routines as needed, for now we only need to get it working with the best fit codecs.

<<<-- Originally posted by Juan M. M. Fiebelkorn :
Lookin for more info I 've discovered some other codecs called EZW, SPIHT, -->>>

SPIHT is the one Silicon Imaging is involved with, I asked Steve about it in one of the threads.

Were lucky Juan P. Pertierra doesn't join us, we allready have more than enoogh ROB's, Steve's etc. ;)



<<<-- Originally posted by Steve Nordhauser : Jason on RS readout:
Wayne:
Camera link does not limit the max clock rate - the on-board A/D and shift register do. This means a local buffer won't speed up the readout. -->>>

Sorry, I was referring to it's use where the peak HD data stream bandwith is above the interface bandwidth (USB2, Gigabit Ethernet, or normal 132MB/s PCI).

<<<-- Originally posted by Steve Nordhauser

There is a definite split here on completely lossless and "virtually lossless" because no one is willing to lose anything too early in the chain but the gains in reducing system complexity are high if you can compress early in the chain.

Steve -->>>

The problem with lossy compression is I think the more you compress the more horespower you will need, which will outweigh other benefits. But Rob's idea of pause processing would be the way to go, because during pauses the computer could perform the slow lossy comporession at 6:1, or 50/100Mb's, and still retain a great advantge over HDV (not to mention that wavelet comrpession produces higher quality at the same rate). There is still the problem that you have to convert to 4:2:0, 4:2:1 or 4:4:4 before you compress, as lossy compressing the subpixels seperately will result in sub-pixel mismatch.

<<<-- Originally posted by Steve Nordhauser : You have more vertical pixels. You could do image stabilization if you record 820 vertical and use the top and bottom 50 rows to debounce the image. It is free once the software is written. -->>>

Yes, good idea. Does anybody know a cheap way to do optical image stabilisation to get rid of motion blur, I was thinking of a glide cam?

<<<-- Originally posted by Steve Nordhauser :
I've been wondering if we are busting our butts trying to emulate film and all its ecentrisities. Is the rolling shutter stuff objectionable or just different? Does it add a feeling of speed? It would crack me up if Lucas adds this effect in a feature film to be different from film effects. Just a thought. -->>>

The problem is that if a person blinks (and they do a number of times) or just shifts what they are looking at (which happens several times asecond) it can momentarily freeze frame the image inside their heads and reveal the slanting bus rolling shutter effect, or if they track the image. If the effect is very slight and motion blur is used it should hide it. I think that as long as you have long integration and fast readout (240th a second), maybe using a buffer, it will be of no effect, isn't it possible just to leave it integrate and read it every tenth 240fps frame or something, some sort of chip reset to get past the one frame integration restriction (they used to use these sort of tricks to tweak computer performance)? George would use the rolling shutter effect if his Starwars characters accidentally fell into a slanting universe ;) what about it George, good idea for a script?



<<<-- Originally posted by Rob Scott : OK, now that the dust has settled a bit ... :-)
Recently I've also run across the Dirac project which also uses wavelet compression (but I'm not sure if it supports more than 8 bits per channel). Dirac is apparently designed to be un-patent-encumbered.

If it's high enough quality, and possible to do in real time, I'm all for doing "lossy-but-visually-near-lossless" (LBVNL?) compression at capture time. The commercial companies like CineForm (IIRC) do this, but they have lots of full-time developers, hardware, tools, money, and know-how. Given our resources, we can't possibly compete with them -- and I don't want to. I think we can do some cool things, but a fully embedded FPGA/DSP system is a long way away unless someone comes on board who has a great deal of experience with it.
-->>>

Don't let the 8-bit restriction fool you, the basic structure should be the same, but the upper limit and packing would need to be adjusted, so Dirac might be good. I personally think we should have lossless down to 50mbit/s lossy, but extra compression requires more processor horsepower, and lossless would be the most portable balance (due to processor power consumption and heat issues) for the moment. Within a couple of years this will change as processors increase in speed, but clearspeed is here today and probably much much faster. When you go into high compression extra horsepower would produce better realtime results. As far as I know a hardware compressor from JVC will cost many times more than the whole HD!) camera, and be bigger for this reason. The clearspeed is a revolutionary solution, I have been involved with people wanting/trying to develope simular products, and I know that this really is probably the solution for the future, programmable in C.

Your other comment. I had previously shown interest in a commercial solution to save you guys the trouble, or to allow you to do a wordpad/write edition with good camera controls, while the commercial company offered the Microsoft Office solution for anybody with the money.



<<<-- Originally posted by Obin Olson : Ok I am fired up now!!

http://www.damnsmalllinux.org/

it could be loaded on a flash card. No need for a 3rd disk drive for the OS -->>>

Look for embedded linux over at Transmeta processor site, it was made by the Linux founder. www.qnx.com and Toas (also now used by www.Amiga.com Digital Entertainment environtment who have extra front end and interface tech) can be measured in hundreds of K. I am a bit biased because I know these environments could outclass Linux in performance in the old day and efficency and Toas tech will run unmodified code under Windows, Linux and other systems.

<<<-- Originally posted by Obin Olson : I found a guy that says he can help design and build a stand alone camera using DSP and FPGA stuff with NO computer..like the Kinetta camera..has has been doing DSP and FPGA for years and really knows that stuff...will keep you posted -->>>

I have too, see below.

[Wayne Morellini]

<<<-- Originally posted by Jason Rodriguez : Gosh, I hate to sound like a broken record on this, but that's basically what the Kinetta is.

I'm not trying to say, "don't bother, it's already been done", but if you're going to sink that much cash into a project for all the R&D it's going to take to do FPGA's, etc., then you'd better think of a way to make your solution either much cheaper, or fulfilling a specific niche that the Kinetta doesn't. Because IMHO it makes no sense to spend $20K on a camera that can't do half of what a $30K camera can. That's just the nature of competition. If we can keep the FPGA "hard-disk dumping" solutions below, say approx. $7K (with bundled bayer conversion software), then I'd say very, very nice, you've got sales. -->>>

Eventually it canbe done at a fraction of that price, but at the moment we can bypass the need to do that, and in future it will be even better without FPGA's. I personally have been in contact with somebody that would like to do simular FPGAS later this year, but I havn't mentioned it because the person hasn't annopunced any commitment to it here. So be patient, it may or maynot happen, but still I recommend clearspeed for performance, power and cost advantge. There is also FPGA comrpession designs on opencores.com anyway. We are covered and not with the overhead of Kinnetta. I personally am interested in a low entry piont (3 chip though, or 16:9 8Mpixel bayer) for myself and anybody else, and anybody can add what ever they want to it. When I was in college, and since, I came up with ways to cut production costs down to figures like one tenth. So one day I would like to see just how much canbe done on how little.

<<<-- Originally posted by Jason Rodriguez : Once we start including ProspectHD/Boxx dual Opteron/big RAID's, etc., then we're talking $$$$. Of course nothing agaist any of these products, I'm just saying that you will quickly find by incorperating these products into the system, the cost will quickly climb.
-->>>

Jason, that is top of the line sort of indie equipment, we are talking of using bottom of the line equipment to do the same thing, that's the advantage, but anybody can use the more excpensive equipment if they want, that is one of the flexibilities we are looking at, an open staggered capability going from low cost levels upto Kinnetta cost. This will all need volume, but even not, there will be people who will take a industrial/security camera and use it for video anyway.



David your bayer compression idea, spot on, very good suggestion from an expert understanding. I still don't like the fooling human eye techniques, I think they mainly work because we don't take much notice of them, but for bayer it is mostly that way allready anway. There are simular things in audio, you don't notice what the difference is, but you defintely can feel it, so I would still like to see 4:4:4 someday.



<<<-- Originally posted by Juan M. M. Fiebelkorn : Just a thought.Wouldn´t be useful to have a sticky thread with a compendum of all this technical things to be accessed in a simple way?

I mean chips, software tools, codecs, camera sensors, shutters, raid cards, source code, etc,etc.
-->>>

I have suggested a solution to Bob a few days ago, where the first post of a thread can be continousely updated to contain links to the wiki and other info. Rob is looking into it.



I stumbled accross a D-Link 802.11g Wireless card in a local shop it said it had a turbo mode of 108Mbps, I don't kno wether it uses some compression or not, but it raises a question, can multiple channels be used at once to transmit a compressed signal to base? I say this because I would like to use some form of wireless standard to trnsmit a HD signal from a remote controlled model aricraft to a base station. Does anybody know of a wireless standard that can do this at raw 720p/1080p rates?

I was also down at Big W (Australia) and bought McGraw Hill's "DTV Survival Guide" by Jim Boston for $6 from a clearence table, which is probably less than a tenth of the price. So anybody over here next to a Big W check it out.


Obin, I have just located some ITX boards with gigabit Ethernet:

www.digit-life.com/news.html?106173#106173

www.ibase-i.com.tw

To answer your question on PC in your camera, try nano-itx or one of the other suppliers of small formfactor I mentioned in the Viper/10-bit threads. If they have Giga Ethernet, then that eliminates the space of a PCI card, though youal need the adaptor instead. Then you'll need a notebook or smaller drive, to give you more space you could tac on a case with main baord or other compoinents outside the camera on the side or back. If anybody uses clearspeed in the future it should be very possible to fit everything in except extra drives.


Forgot to mention, I am just about to update the sound and battery possibilities over at the Viper thread. Some substantial information.

Thanks

Wayne.

[Juan M. M. Fiebelkorn]

More interesting links about FPGA, microcomputer....

SUSAKU PROJECT

http://www.atmark-techno.com/en/product/suzaku.html

http://suzaku.sourceforge.net/index.php/SuzakuHardwareInfo


@Wayne

BTW, if you have read all the posts, you would have noticed that I'm not only talking about lossy but also about lossless (mathematically lossless compression).HDCAM SR also uses compression and it is supposed to be lossless (I don't know really).
I've been working with HDCAM since January 2000 (I guess that feature film was made before Starwars, and was the first in Latin America shot with Cinealta Camera) and seeing how good it looks once on film, and knowing (and suffering) how crappy HDCAM is, I believe that anyother kind of compression, even lossy, would give far better results (I'm talking about several compressions discussed in this board)

Anyway I think that at this moment an uncompressed solution against a lossless compressed one would be far costly in $$$.

I don't quite understand why everybody thinks FPGA are so expensive.The only thing needed is people with a decent knowledge.

[Wayne Morellini]

Folks, I have been having troiuble with my health and even though I have felt a bit beter in the last hour, it is likely to be persistent for a while. So I will be turning up weekly at the most for the foreseeable future, though there are some things I will be emailing the Robs on to do with sponsorship. My case projects will have to be put on hold/slow mode. Continue on the good work you guys are doing great.

Juan

I'm not saying your not, but I was saying that not all of us here are lossless only. I do think there is some missocmmunication here, as I was a bit confused as well as to your meaning. Which movie was the one before Starwars, that you were talking about.

The FPGA is expensive, because somebody has to design the FPGA and circuit board. Clearspeed is programable in standard C routines, so routines can be much more easily transfered over, and probably more powerfull and cheaper with lower power consumption. Nobody is really against these solutions they are just harder so we are leaving them to last.


Obin, I forgot about the keyboard thing. Those prices look expensive, if you buy Circuit Cellar Ink, you will find people advertisng Keyboards in the back. Some electronic parts stores (like Tandy) may also have non pc baords, I was thinking that we may be able adapt external Lanc/firewire DV controls.

thanks

wayne.

[Steve Nordhauser]

On the FPGA/DSP idea, if someone comes up with a person with a full hardware design (schematic) and tested FPGA design for compression, I'll do a run of boards that can be integrated into the cameras. I would have to work out the licensing and all but it is something we would like to add to the cameras but don't have the resources.

[Obin Olson]

what type of compression are you talking of Steve?

[Steve Nordhauser]

Obin:
GOOD COMPRESSION, SIR!

Either lossless or LBILI (my new acronym - 'lossy but I like it' - visually lossless or whatever we care to call it). Both have their place in this world. Either would enhance a camera. In a beautiful world, the FPGA would be loadable with either algorithm to fit the user, weather or color of your mood ring.

Sorry, went to a traditional folk music festival this weekend and seem to be have a problem adjusting to reality.

[Rob Scott]

Steve "reality challenged" Nordhauser :-) wrote:
In a beautiful world, the FPGA would be loadable with either algorithm to fit the user, weather or color of your mood ring.

Some of the cores on OpenCores look pretty interesting -- they already have cores for:

• 8x8 fully pipelined parallel DCT. Provides a DCT result every clock cycle.
• QNR. Quantization & Rounding Unit.
• Run-Length-Encoder.
• Huffman Encoder / Decoder.

When this first project is done, I may have to look into FPGA programming. It looks very interesting.