Record uncompressed 14-bit (4:4:4) on your HVX200

Juan, are you able to now apprise us of how timecode and/or audio is, or is not, dealt with/recorded in respect of Hydra, and the proposed process when dealing with post production? Thanks.
 
pertierr said:
I'm glad pixel-shift was brought up because it seems like this is an area of some confusion. Imaging sensors are monochrome("grayscale") by nature, so if one looks at just about any single-sensor digital cinematography camera such as, say the Arri D-20, each pixel in the sensor only records one basic color, either Red Green or Blue.

Pixel shift, in simple terms, combines 3 sensors each recording one color(red, green and blue) into an imaging block that functions similar to how a single color sensor of higher resolution works.

In other words, when talking about a pixel-shift 3CCD assembly, the native resolution is the resolution of the entire imager block, not just one sensor. In the case of the DVX this is 1540x984.
I agree with that as far as it goes, but are we not then talking about luminance resolution only? The sort of resolution we could see if looking at a black and white test chart? Whereas if a camera such as the HVX looked at a chart lit by pure red or green light, say, the resolution is inevitably limited to that of the red or green sensor only (960x540) - the other two cannot play any part in the imaging process.

In other words, if we are talking about true 4:4:4 imaging, it is impossible to get any better than 960x540 out of a sensor arrangement such as used by the HVX. If we are talking about 4:2:0, then I accept that pixel shift allows the luminance resolution to be higher, but surely the CHROMINANCE resolution must be limited to 960x540 still?

None of this is to denigrate what is being talked about here, I accept it could give far higher results than the native camera.
 
New forum thread under HVX: Hydra?

New forum thread under HVX: Hydra?

Dear moderators, I think it might be a good idea to make a new thread regarding Hydra. The anticipation is iiiintenssssse... :laugh:
 
pertierr,

Any reason why there is no support for Windows or Linux? Non MAC laptops are so much cheaper and most of the time more powerful for half the price...
Either way it's still exciting news.... especially for green screen work! We are going to mod one of our HVX for sure!!!!
 
Juan has stated that they already have plans to support Windows platforms, but will make the OFFICIAL announcement around NAB or during, maybe after. But they have not ruled out PC users this time around.

Be happy... dun worry, be happy now.
 
Hydra is looking impressive. It is making the DVX mod look that much better. So now you can get 2K uncompressed for under 10k I am assuming. That is great I sure would like to see a compressed codec integrated into the hydra. 2K is cool but 2k file size is not cool. Great Job!
 
To elaborate on the PC support issues in the past, our current Andromeda system for the DVX works over USB2.0. This is one of the main reasons why we could bring this system to market for such a low cost. The main 'PC' problem with USB2.0 however, is that there is no minimum required data bandwidth to be supported by USB2.0 hardware manufacturers(the 480Mbps number is just marketing).

Apple machines(with a few older exceptions) have a fast enough USB2.0 bus to support Andromeda. PC's, on the other hand, have all sorts of varying performance and the only way to find out if a system performs fast enough is to test it. It then becomes a significant problem if we need to test even a few of the hundreds(and ever-changing) PC models out there for compatibility.

With gigabit ethernet, this should not be an issue anymore. Unlike USB2.0 which requires a lot of attention from the CPU, Gigabit ethernet controllers are designed to talk directly to memory which means the bandwidth is always very high.

Our goal is to support WinPC's and possibly Linux, although we will initially be releasing with Apple support. One step at a time. :)

harddrive: native frame size is basically pixel-wise what size frame the raw output from the imaging block fits into. You are correct that resolution is measured with a black and white chart, but that's a convention we have to follow. One thing that is often overlooked is that the RGB space has a lot of overlap and captures more color information than the YCbCr space. In other words, saying that full bandwidth RGB is (Y:Cb:Cr = 4:4:4) is a convention but not strictly accurate, as RGB contains more information.

The question you post: "what if I have a perfectly red resolution chart?", is one that I've asked myself, but once you -really- think about it, is more of a theoretical exercise than anything else. It's practically impossible to get an entire scene with all parts recorded by the sensor to be perfect Red as recorded by the camera, that just doesn't happen. Second, if the lines of the chart are red, then what is the background? Any way you look at it, the sensor will resolve edges anyway. :) This all-red(or blue) chart question is actually a problem if you have 4:2:2 or 4:1:1 or 4:2:0 YCbCr encoding, as many have already found. When you have RGB samples all over the place, there's a lot of colorspace overlap.

Cheers,
Juan@reel-stream.com
 
Last edited:
Thanks for clearing up the andromeda PC deal, Juan. That's what I thought, actually. There shouldn't be varying speeds between the two platforms as far as Ethernet controllers go, it'd be pretty much up to making sure that you have a newer PC and the newest drivers for your chipset/motherboard.

Any projections on support for Vista 32 or 64-bit platforms? I think being able to take advantage of a ram-packed system would be ideal for Hydra. At least 4Gigs of DDR2 PC4200 in the year-old systems would fair better than XP's 2gig max.
 
Just to triple check, even a Hydra HVX still keeps all original functions, correct? If I were to get the mod, but not use it for run and gun projects, the HVX remains 100% operational as it was before.... correct?

I'm totally blown away by the hydra, if what I said above is true, i would jump in line for one, but then again I don't have a fast enough notebook. That would tack another 2k to the cost. :(
 
That's my understanding from the documentation. You can do either or, or both simultaneously, if you want a p2 back up (which would be regular HVX, of course).
 
pertierr said:
The question you post: "what if I have a perfectly red resolution chart?", is one that I've asked myself, but once you -really- think about it, is more of a theoretical excersize than anything else.
Not quite - a resolution chart lit with white light will indicate luminance resolution, but will tell you nothing about effective colour space of the system, the ratio of luminance/chrominance resolutions. But comparing the results when the chart is subsequently lit with coloured light WILL tell you a great deal about system colour space. In practical, non theoretical, use, it will have relevance with effects work - green screen is the obvious example. Your approach would enable you to get true 720 4:4:4 out of a JVC 200, for example, as it has 3x 1280x720 chips - it's the HDV coding that there reduces the output to 4:2:0.
Second, if the lines of the chart are red, then what is the background? Any way you look at it, the sensor will resolve edges anyway. :)
I'm assuming a black and white chart, lit first by white light, then (say) red, green and blue in turn. (So red/black, green/black, blue/black lines in turn.) By definition, if the system is a true 4:4:4 one, there should be no difference in the four sets of results. But as you say, 4:2:2 or 4:1:1 coding will indeed make the colour results worse than those for white light.

In the case of the HVX, I'd expect that for white light the effect of pixel shifting would give an improvement in resolution of about 1.4x horizontally and vertically, so about 1300-1400 horizontally. (Though in practice it will taper off, and an absolute figure is difficult to give.) But for coloured light the pixel shift effect cannot work - only one of the sensors is active, only one colour of pixel - so the resolution in this case limits at 960. Yes, the sensor will resolve edges, but only one sensor.

I don't doubt that your approach is very valid, and will give a worthwhile boost to the HVX performance. But you claim that: "The system extracts pure uncompressed 2K RGB data available directly from the digital imaging block of the camera......" and I don't feel that's accurate. What it extracts directly from the block of the camera is 960x540 RGB data.
 
The imaging block on the HVX is roughly ~2k, and the raw data is RGB uncompressed. I'm not sure what's innacurate about that.

What it extracts directly from the block of the camera is 960x540 RGB data

I'm sorry, but that's incorrect. Each -CCD- is 960x540(actually considerably more than that). The imaging BLOCK composed of all 3 sensors is ~2K. That's the optical resolving power of the imaging block, not 960x540. If that is so, then explain the resolution charts that even the standard output from the HVX gets.

So would you suggest that all digital manufacturers should change their specs as well? For example, silicon imaging should advertise their camera 960x540 RB and 960x1080 green? It's the same concept. The native frame size of the Altasens sensor is roughly 2k x 1080. I don't hear anybody telling them, or Arri, or Panavision, to change their specs just because their sensors record at most one color per site. This is the way many sensors function(except Foveon), in a sense this is how film functions, and if you put any camera under perfect red, or blue light only you will obviously see different characterstics than if you had a real-world, balanced image. No camera is perfect.

Don't get me wrong, I understand what you're saying and I love these deep technical discussions, but if we're going to test one system under some unique, theoretical conditions, let's test ALL of them, shall we? :) We all know what one means when we talk resolution, and the test for resolution is well established using a high-contrast chart with grayscale trumpets. If you are arguing that the common definition of resolution should be changed, then that's fine with me, but let's make sure it applies to everybody, otherwise it's a useless measurement for comparison.

Cheers,
Juan
 
Last edited:
Juan,

This is exciting news about possible PC support!!!
We were looking into aqcuiring a silicon image or a Red camera. Instead we are going to mod our existing HVXs. When can we pre order????...
WE WANT IT NOW!!!! :love4: :thumbsup:
 
Juan, I think my question got lost within all the others above. As a potential long form user of Hydra, please expand on how timecode and audio recording is, or is not, dealt with/recorded to the hard drive (via gigabit?)? Thanks
 
Will it be possible to capture kind of uncompressed (slightly uncompressed)? That is something I would be interested in.

Again Great Job!
 
Last edited:
HYDRA
-Uncompressed 14 bit
-2k resolution
-4:4:4 color space
-Under 10k
-Variable frame rates from 2-60p in 2k resolution
Am I crazy or is this better than what Sony F950 offers?

VIPER
Captures raw data directly from CCDs
Unique 4:4:4 RGB Dual Link FilmStream output
Native 16:9 or 2.37:1 aspect ratios without resolution loss using Dynamic Pixel Management™ technology
Patented Frame Transfer (FT) CCD technology
Mechanical shutter guarantees no vertical smear
Multiple format support:
1080p @ 23.98-, 24-, 25-, and 29.97 frames per second (fps)
1080i @ 50 and 59.94 Hz
720p @ 23.98-, 24-, 25-, 29.97-, 50-, and 59.94 fps
Electronic viewfinder focus assist tools: crawler and zoom

Is it me or does the VIPER not seem so superior anymore.

Add a 35m adapter and you are good. How many hours can you record per 100gb?
Can you record to a mac mini external hardrive?
How much space would you need to capture 2 hours of footage in 2k resolution at 24fps?

Soon I am sure there will be a HYDRA,RED,VIPER shootout!!!
 
pertierr said:
So would you suggest that all digital manufacturers should change their specs as well? For example, silicon imaging should advertise their camera 960x540 RB and 960x1080 green? It's the same concept. The native frame size of the Altasens sensor is roughly 2k x 1080. I don't hear anybody telling them, or Arri, or Panavision, to change their specs just because their sensors record at most one color per site.
I certainly wouldn't suggest that, and having just looked at the Silicon Imaging website I note that whilst they may claim 2k resolution (see http://www.siliconimaging.com/DigitalCinema/News/PR_11_01_06_1.html ) they do not claim 4:4:4. Although their chip may approach 2k luminance resolution, it (like what is being talked about here) cannot claim that for each colour, and hence cannot be accurately described as 4:4:4 - and to the best of my knowledge, they don't attempt to.

And 3 CCDs with pixel shift is not the same as a Bayer sensor, it's not the same concept at all. In the case of the latter, all the pixels are uniquely located, whereas for the former the optical position of the pixels has overlap - indeed, the red and blue corresponding pixels are optically co-sited!! This gives sensitivity advantages of course, and is sensible engineering for a camera with 3x 1/3" chip, but it also means (together with half as many green pixels) that the max theoretical resolution will not be as high as from the SI chip you refer to.

The optical co-siting of the red and blue pixels alone means that they cannot be considered individually for resolution purposes, unlike the situation with a Bayer sensor.
We all know what one means when we talk resolution, and the test for resolution is well established using a high-contrast chart with grayscale trumpets. If you are arguing that the common definition of resolution should be changed,.......
I'm not arguing that at all. Just saying that what you refer to gives no information about colour space, (which is fine in itself), whereas further tests along the lines I suggest will. And to claim a 4:4:4 system, will require the results with coloured light to show the same results as for luminance. In essence, that's what a 4:4:4 system means by definition!
 
Well guys, if people have been getting by with 4:4:4 Andromedized DVX cameras, what makes it so different for the HVX?

Both are 3CCD's, one just has more native resolution than the other, correct?

Based on what I've seen and read from an Andromedized DVX, it will deliver leaps and bounds over what you would normally get anyway.

Nik, nice comparison with the Viper! :thumbsup:
 
Back
Top