Juan,

First off let me salute you for the remarkable efforts you are exerting in this quest. I to would love to see success in the direction you're pushing toward. I do however have serious doubts of you ultimately reaching a usable goal. Considering the necessity to bypass ALL camera features to grab signal directly from the CCD's, I just wonder what is left? If the ultimate goal is to develop a usable camera, where will all these features be returned and how?

I almost think this effort would be better served if started with some manufactured industrial CCD camera and then once proved look for ways to develop your work into a usable camera. At best, all I can see this becoming is an interesting experiment, in and of itself. Whether or not something useful shows up by way of passing through it along this journey, of course is anyones guess.

If you are determined to "build" a processing facility to handle this 40 MB per sec data stream, and all that this will entail, you might consider the alternate possibility of not bypassing the cameras compression scheme, but rewriting it so to speak.

A number of us had a discussion a year or so ago over at 2-pop involving the compression methods used in today in DV codac and how they process black content when using in-camera letterbox mode. It occurred to us whether the upper/lower black bars are actually being compressed, or ignored entirely buy the algorithm. Consensus is that it is still processed. If so, this is one area where considerable improvement/quality could be derived by reworking the codacs algorithm to exclude this area during the compression cycles.

Just some thought here. Again, if you continue your course (as you most likely may), I hope your achieve your goals. If not, then I hope you find some useful knowledge along the way and put that to some practical purpose.

Good luck and good fortune.

-Rodger

Hi Rodger,

I appreciate the input.

First of all, I already have a 40MB/sec capture facility which is comercially available for a relatively modest price. I am using this only as a test platform, and once i get the prototype working I intend to build a small firewire interface/driver which easily handles this data rate.

Just to define 'modest', my entire test setup including the DVX does not exceed $5,000. The final device should not cost more than $50 to make.

Second, the experiment does not necessarily bypass all camera functions. there are two options as described before in this thread: the 12-bit 4:4:4 raw RGB output from the A/D converters, and the 10-bit Y/C output(12-bit for DVX100A) from the main camera processing chip.

I am starting with the 12-bit RGB simply because i want to try and get the cleanest signal for the experiment. An almost exact setup can be used with the Y/C output. The difference is that the Y/C output has most of the camera corrections done on it, yet it is still uncompressed and non-decimated.

Why i am doing it in this order? Simple. The 10-bit Y/C output needs less bandwidth. If i can get the RGb output working, I can not only compare the two and see the quality difference, but it is guaranteed that the system will work with the smaller Y/C datarate once proven to work on RGB.

About using an industrial camera, have you seen how much they cost? This is more cost efficient, and I get great SD CCD's. Besides, I would like this to be something everyone can use, not some monster made from hard-to-find parts that sits in a closet.

Good luck Juan. As I said, I hope you achieve your goals.

BTW, I am buying the DVX100a this week. I have been trying to buy for over a year, but with life's struggles, the possibility has not presented itself until now.

If you succeed, I'll be waiting in line like everyone else.

Take care.

-Rodger

The DV algorithm is indeed compressing the black bars. Why?
Because it is a constant bitrate encoding that is always using
the same amount of compression on the same amount of macro
blocks.

Any schematics available?
 

Ola Juan,


congratulations to your challenging plan! I wonder if the DVX sports a programmable DSP or the DV25 hardware codec Panasonic used in the past. These chips could be cascaded, therefore DVC50 machines had two of them, while DV100 (HD) systems were built around a matrix of four. I assume you know that FCP 4 already supports DVC50 over Firewire, thus the question is whether it would be possible to alter the digital data and hence the format by means of the firmware, assuming there is a DSP capable of transformations beyond 4:1:1. Probably this wasn´t your exact intention, but imagine the benefits of a hard drive firewired mobile DVX writing DVC50 streams. From my experience, the colour compression has the highest impact on the image´s look. Detail compression artefacts are normally inconspicuous, but the typical contrast halos strike the eye even in Digibeta recordings. Naturally the best solution would be the 4:4:4 uncompressed way, but I am a bit afraid the D1 words won´t be satisfied with firewire, let alone the drives. So what is the state of the signal at the Y/C stage you mentioned? Is it still 4:4:4?

Lucia,

Thanks for the input. What do you mean by 'D1 words'? Do you mean the bandwidth of the uncompressed 4:4:4 signal?

From my rough calculations it seems like any modern computer mounted harddrive should be able to keep up, as long as that's the only thing it is doing. I know firewire 800 can handle it at 24fps, although FW400 is right on the edge, and might not be able to mantain the data rate needed.

In the worst case, the portable interface can be designed so it interfaces to a triple firewire or ultra-ata, and record each color on a different hard drive which can be carried as a shoulder bag, or something of the sort.

however, i am pretty confident that any computer with FW800 will do.

The reprogramming of on-board logic is indeed a very interesting question...the main problem being that in order to do that, i need tons and tons of technical information about the IC's used in the camera and how they are used. This information is usually not easy to come by. My approach relies on components present in all cameras now days so it's more straightforward in that sense...although yes, it would be nice to be able to implement, say DVCPRO50 right on the camera....but that would be a much more expensive and time-consuming endeavour, and still my approach should yield a cleaner signal.

Juan

D1 over Firewire 400
 

Juan,

the uncompressed signal you are getting from the A/D converter stage would most probably be some form of D1 data stream, which is 4:4:4 SD at 8 bits nominally, and 12 bits in your case, used as an intermediate step for CGI and the like. However, my approach was that there are already simple firewire 400 harddrive recording devices designed for the very purpose of direct-to-disk streaming and a DVC50 via firewire protocol. Let us assume you could get a 4:4:4 8 bit quantisized signal at the Y/C stage, which should equal about 30 MB/s. The best 7200 rpm single drives can sustain that in combination with the newer FW400-to-IDE bridges. For PAL, the total recording time for a cheap 160 GB drive would be about 90 minutes. Furthermore, I expect the enhanced headroom of the 12 bit resolution to absolutely make sense during the image taking process, but not too necessary for the recording itself. Think of the DVD as a principle - high quality input (film) and thus high quality output in the dedicated environment (TV). So if the firewire protocol could transport the untamed Y/C data, we would have a simple and mobile means to capture undistorted images for mattes or compositions.

Ah, i get what you're saying...

I think you might be over-estimating the output from the A/D converters. I am not knowledgeable on the technical details of how D1 is encoded, but the output from the A/D iscompletely dependent on the output of the CCD's. For example, it outputs a non-standard frame size along with many dummy and black pixel values. From the little I know, D1 SD is standard NTSC frame size, so right there it wouldn't work. There are several other reasons but I won't go into them because like I said, i'm not sure what the D1 standard implies at the lowest level.

The Y/C 10-bit output from the main chip might be a better bet...however, I am unsure at this stage if it is still 4:4:4...i ~am~ sure, however, that it is still uncompressed, and contains all camera corrections.

I guess on a DVX100A, even if the Y/C is already decimated to 4:1:1, it would be uncompressed and 12-bit color, so it would still be worth while due to the much higher color precision and uncompressed nature.

Juan

Will it still retain....
 

am~ sure, however, that it is still uncompressed, and contains all camera corrections.

Will this approach still retail all the great aspects of the DVX for instance frame rate, shutterspeed, gamma etc?

Either approach(RGB straight from A/D's or the Y/C corrected) will have the progressive frame rate, and shutter. only the Y/C would have the gamma corrections made to it.

The idea is that with 12-bit 4:4:4 uncompressed footage, it is a trivial matter to load up the frames into your favorite editing program and do gamma corrections as you like.

Those of us that have tried to accomplish a film look with a camera other than the DVX know it's pretty simple. And with a full color, uncompressed frame to start with, the results will be so much better than starting with DV.

Juan

Decimation
 

Juan,


can you give me the name of the main chip in the DVX? I might be able to evaluate my estimations in the first place, whether it is still the old DV25 hardware codec with fixed decimation or a new, more versatile DSP. Call it a hunch, but I wouldn´t be astonished if the DVX uses the same DSP like the 900 for instance. In the last years, LSI developing significantly surpassed manufacturing in costs. It is simply more economic to have one chip design for all purposes. From my adventures with various editing suites and gearings, chroma compression can become really frustrating especially in matching real life shots and composed elements and is highly responsible for the video look. But don´t take me wrong, it´s definitely worth a try. Thank you again for your research and share of insight.

it is an Atmel microcontroller, so it is hard to know what it does without somehow downloading the code with which it was programmed.

DSP
 

Very nice, so at least it is not the old all-in-one codec. What´s the proper name? By the way, if you happen to have a scope you might be able to scan the carrier frequencies in the Y/C stage. These should be around 13,5 MHZ for 4:4:4 and 6,75 MHZ or 3,375 MHZ for 4:2:2 or 4:1:1 respectively.

Question...
 

Ok, this is a question to everyone who is interested in this idea.

I've gotten a ~lot~ of emails from people who are interested in doing this to their DVX's, asking how much it would cost. Now the reason I am writing this, is because I am at a stage were i have to make a choice, whether i purchase a last piece of equipment for test purposes, or to actually design this to be encased in the DVX itself.

So i guess my question is, how many of you would be interested in having this installed on your DVX, and how much would you pay? The assumptions are that it provides 4:4:4 12-bit uncompressed full CCD frame resolution video at at least 24fps (progressive of course). Also, that it is that the DVX will work as normal, completely assembled, with the only changes being a ribbon cable coming out the back and hooking up to a small box mounted on the camera itself.

Note that the $25,000(+lenses) SDX900, puts out 4:2:2 with 3:1 compression and standard frame size. The setup I am describing here would provide much better quality video, the only differences being the glass and the CCD size(correct me if i'm missing anything, i know there are extra gamma settings, etc but i've never used an SDX).

Juan

Juan,

If you can produce what your saying you think is possible, then money isn't (won't be) the issue. What is at issue, is whether or not it's possible.

I would therefor suggest you provide a working prototype or at least prove your theory with an actual working design, even if using bulky parts that would never sell as a prototype.

I would further suggest to those who desire this to work so much they are entertaining some form of financial support, be very cautious. This is at this point, this is only a concept and in no way a reality.

Again, I hope this is possible for you Juan and that you succeed in you quest and develop a working model or prototype.

-Rodger