Amd?
 

Has anyone tried recording on an AMD based PC?
Maybe something with more than 3 GHz?

Yes, I actually have a dual Opteron 252 box that I do most of my work/testing on.

The 252's are single-core at 2.6Ghz, so I would say they would fair favorably with a FX-60, and the newer FX-62 or 5000+ should be a little faster.

My Opteron basically eats anything we throw at it.

Also the system at NAB was AMD-based . . . it was a 275HE, so it was pretty quick.

I would still recommend, if you want to use an AMD system, to get an Intel PCI ethernet card (Pro1000 based). We have the best drivers for that card/NIC combination (any Intel Pro1000 ethernet adapter, whether it's on a motherboard or PCI card will work nicely).

Thanks, Jason.

My desktop pc should work then, but are there any AMD notebooks that would do the trick?

I think there are desktop replacements from places like AlienWare/Dell.
The Athlon 64 x2 5000 are going for great prices to compete with Intel. The 5000 compares well with the midrange of the new core 2 duos. An over clocked 4800 might be even better since it has larger l2 cache.

AMD's main strength is that they have great memory bandwidth.

At this point in our processor "qualification" we've focused mainly on mobile processors. In this category all our time has been spent evaluating the new Intel Core Duo procs. The "Yonah" category of processors requires a minimum of a T2600 (2.16GHz) to acquire CineForm RAW with the SI capture application at HD (1920 x 1080) resolution.

I think when the camera actually ships we'll be recommending the new Merom processors for mobile (laptop) apps. Not sure which speed spec we'll recommend yet, but it'll probably be either 2.16 GHz or 2.33 GHz. There are some new features likely to be announced for the camera that will require some additional horsepower over the current features that run on Yonah.

At this point we simply haven't evaluated AMD mobile chips. We'll probably have to leverage the collective community for feedback on AMD mobile chips.

2k? Ready to deliver from next September? As $12,500 offer?

<Je vous remercie>

Mums the word from me. I'll let Ari or Jason talk about unannounced features when they're ready. But good things are coming....

Like 120fps at 720p or another 3megapixel version camera also...pss...psss...keep the secret :) Silicon RULEZ!

Yeah sounds like a treat! :)

On another note.. so the Cineform compressed data you get from the SI is always 10 bit, right? Any chance for going up to 12bit perhaps some time or wouldn't that make any sense? Just curious how much you can push the aperture range the cam can capture raw... (on a side note andromeda (the DVX100 raw mod) went with 10 bit too instead of the original planned 12bit because it didn't make much sense cause there wasn't just much more sensitivity (non-noise ;o) to begin with)

We gonna wait september to know how they will tune the camera specs, but I believe that Silicon Imaging did the trick! :)

12-bit doesn't gain anything over 10-bit because we're already doing a gamma correction/LUT that takes the photometrically linear dynamic range of the 12-bits and maps it into a "visually linear" 10-bits . . . in other words, the 12-bits of linear signal that a sensor puts out is really only 10-bits of actual human-viewable dynamic range. A 12-bit linear signal is really, really dark, and has to be gamma corrected. Once you gamma correct the signal there's only 10-bits of "real" dynamic range to work with . . . so we can losslessly go from 12-bits to 10-bits without loosing any of the dynamic range of the camera.

In theory we could do 12-bit linear compression, but that is horribly inefficient because of the way values are mapped in a linear signal-you waste half your available values compression noise in the highlights (the last bit in a linear image, which is the upper-most highlights, comprises half the values in the total dynamic range of 4096 values) that should really only account for less than 10% of the actual dynamic range of the image like it does in a gamma corrected image, not 50% like it does in a photometrically linear signal.

If you need 12-bit linear, we have a 12-bit linear RAW uncompressed mode as well, but the workflow involving uncompressed is nowhere near as efficient, smooth, and powerful as CineForm RAW (especially when you consider storage space, the elimination of the offline/online process, and real-time workflow speed without a compromise in image quality) . . . . it's there for "special" circumstance, as another tool in our box of goodies.

Thanks Jason! Well that's the same with Andromeda or the Drake Cam ... the 2 more bits at the end just would give you more "noise information". ;)
That's all I wanted to know. Are there any sensors out yet that give you more "real" dynamic range than 10 bits?
And btw. if you update the sensor you use some time, is there a viable upgrade path for existing owners/users or don't you plan on something like that? Would this be a whole new model than?

There's a distinction I'm making here . . . I'm not saying that the extra 2 bits are "noise" . . . that is definitely NOT the case with our sensor. The Altasens sensor has a very high S/N ratio (>69db), and as a result, there is more than 11-bits of "real" information in the linear data . . . the bottom one-to-two bits are *not* noise like they might be on other sensors where the S/N's are at or below 66db and PRNU can be quite high(photo-response non-uniformity is a measure of pixel-to-pixel variation on a CMOS sensor and even though S/N ratio's can be good, high PRNU values can hurt your overall dynamic range since you have to-do some DSP to the image to get rid of the non-uniform values. Since the non-uniformity is typically a fixed value in a CMOS, this is easily done with a gain-offset, but that operation, while creating a clean image, is subtracting from the overall image dynamic range).

What I'm saying is that *visually* you can't work with a 12-bit photometrically linear image. It would look very, very dark to you. You HAVE to gamma correct the image in order to use it. Once you apply gamma correction, there are only 10 useable bits really left in the image . . . or should I say, you only need 10-bits to encode the visual distribution of the data after a gamma correction.

It's the same concept as logarithmic encoding . . . a 10-bit log file was made to hold the same dynamic range as a photometrically linear 14-bit file. Linear encoding of real-world data as our eyes perceive light is very inefficient, because again, the highlight areas of the image, which for us may account for only 10% or less of the actual visually percieved dynamic range of the real world, can account for over 75% of the available linear encoded values if you include the upper two bits as "highlight" areas (which they are). As a result, once you gamma correct, which compresses this 75% losslessly (as our eyes preceive the natural world) into 10 or 15% of the total space, it's pointless to keep encoding at the same bit-depth . . . a bunch of the values in the linear range are not using as many encoded values any more . . . so you can use a gamma corrected 10-bit image to losslessly represent a linear 12-bit image.

It's not a case of throwing away the bottom two bits as noise. That does happen on some sensors, but that is not why we're doing only 10-bit recording with our camera and CineForm RAW.

Of course you can't "directly" work with a >8 (or 10) bit image without any kind of "correction" - at least temporarily while it's displayed. But I was asking because while recording it's a great thing to be able to record the most information or range the sensor is able to capture. Of course you should always expose correctly.. but it's great (and sometimes even a lifesaver) to be able to crank up exposure in post (or lower exposure) instead of having clipping (be it clipping to white or black) or not enough details in these areas. So you're basically capturing to 10bit log? Of course I know the difference ... for example scanned film is mostly processed as (cineon) 10 bit log or 16 bit lin! That's all what I wanted to know. 10bit log is great!