Jump to content


Photo

How does the camera compare to Red?


  • Please log in to reply
34 replies to this topic

#21 Glen Alexander

Glen Alexander
  • Guests

Posted 27 May 2008 - 04:09 AM

threading is always an issue with windows, with xpe or bart you're just limiting your liability.

a tuned linux or bsd kernel will always trump any microsoft os, it's the nature of the two differences in philosophy.

i'll take RAW LINEAR dpx uncompressed files over any compressed LOG format any day.

adobe QT? why bother, it's just about the worst codec available.

if you're going compressed, look at a professional codec like one from blackmagic. www.blackmagic-design.com

while this product seems must more stable than red and on the market, to me the question comes down to what has been shot, who is using it, who is planning on using it? i've only read about music videos and small indie movie. while not having the red fanboys to generate PR or sodaberg or jackson, one has to wonder if eventually this will go the way of the kinetta? a good technical effort but no marketing and a recent big jump in price.

Edited by Glen Alexander, 27 May 2008 - 04:12 AM.

  • 0

#22 Jason Rodriguez

Jason Rodriguez
  • Basic Members
  • PipPipPip
  • 175 posts
  • Cinematographer

Posted 27 May 2008 - 11:18 AM

There is a 12-bit uncompressed mode that gives you the full linear dynamic range from the sensor, pixel-for-pixel how it was transferred from the A/D converter . . . doesn't get much better than that. It's a custom file format called .SIV, but IRIDAS supports it in their SpeedGrade and FrameCycler product-line, so you can use any of those products for batch conversion to DPX files. We also have a DNG converter for the .SIV files in the camera software itself that re-wraps the RAW data from the SIV and puts a DNG header on it so that it can be opened directly in After Effects, Photoshop, or any other RAW converter that supports DNG files. Now this is the standard DNG file format from Adobe (which they have now submitted as a ISO-standard), not their "Cinema DNG" that they announced this past NAB, which is a forthcoming format.

Point is we can deliver a great workflow using compressed wavelet (CineForm), which BTW is very light compression at only 3.5:1 right now, or we can give you full uncompressed 12-bit linear. Your choice.

Finally, yes, you are right, a well tuned Linux kernel can beat the Windows XPe kernel for speed, only problem is that we would have to-do the tuning ourselves, and if you 'hand-tune' it wrong, you create instability issues . . . now when there's a "bug", you're not sure if it's at the OS level, or in your software, or what, so development/support issues get compounded and everything gets exponentially more complex. It's much easier to know you're using a stable kernel and then isolate any issues that are in the software-only rather than having to fish around for issues at the OS level.

If you don't tune the Linux kernel and are just using the vanilla distributions, then the differences between XPe and Linux become more subtle, especially again when you go back to the issue of custom hardware driver support, and the stability of those drivers.

Thanks,

Jason
  • 0

#23 Glen Alexander

Glen Alexander
  • Guests

Posted 01 June 2008 - 12:09 PM

windows is horrible with drivers and compatability. try tracking down a DCOM bug or a timing issue, and watch microsoft blame the hardware mfg, the hardware mfg blame microsoft.

With most linux/bsd distros you can obtain source code and re-compile. trying getting any source code for any windows driver or ms with paying huge royalty fees.

no one in any professional engineering environment worth their salt, would use a plain kernel out of the box and wouldn't recompile the kernel, the video drivers, network, etc. specifically tuned for their hardware.

a stock BSD kernel out of the box installed as server will thrash any windows os.

what about the marketing issues?
  • 0

#24 Matthew W. Phillips

Matthew W. Phillips
  • Sustaining Members
  • 1609 posts
  • Other

Posted 01 June 2008 - 01:29 PM

no one in any professional engineering environment worth their salt, would use a plain kernel out of the box and wouldn't recompile the kernel, the video drivers, network, etc. specifically tuned for their hardware.


Anyone else notice the "Appeal to Authority" logical fallacy here? I detect a Linux fanboy...it's no use reasoning with fanboys of any sort.
  • 0

#25 Evangelos Achillopoulos

Evangelos Achillopoulos
  • Basic Members
  • PipPipPip
  • 102 posts
  • Digital Image Technician

Posted 03 June 2008 - 04:07 PM

Jason

I'm following SI from the first forum announcement I followed the "spoon" demos, I also followed RED.

I haven't invest in RED yet.

My biggest problem with SI is the size of sensor. I cant accept that I will buy another 2/3 camera... SI/2K is beautiful and the experience of Alfred (P+S) is a big add. But to buy a new camera without DoF of 35mm, again! it hurts badly.

To have to buy a PRO35 for SI/2K with all the problems that are introduced, plus the huge cost (compared to RED or the SI/2K it self) it just meaningless.

I already have a Varicam that performs very reasonable but again with all the DoF adapter problems that I may have...

But another 2/3 is not an option for me. I wont even try the new Varicam 3700 regardless quality/resolution, never a 2/3 again in my shopping list.

Anyone that says that a good Digiprime 2/3 would be equivalent to 35mm DoF, he is just try to convince himself for the lack of DoF.

I'm not trying to round up things, no DoF 35mm IS a huge problem. Whatever you do, the feeling, the image, its not the same.

I have to accept this, RED has it and its a big plus...

But why not a 35mm size SI/2K? why didn't you build one in the first place?
  • 0

#26 Glen Alexander

Glen Alexander
  • Guests

Posted 03 June 2008 - 05:17 PM

Anyone else notice the "Appeal to Authority" logical fallacy here? I detect a Linux fanboy...it's no use reasoning with fanboys of any sort.


Notice the ignorance of people who can't or don't do anything but only doubt the people that have done.

There is a difference of wannabees like you and people who have and are professionals.

Watch out before you start slinging words like 'fanboy' around. You 'sound' like someone who probably couldn't detect their own a_s from a hole in the ground.

How does your detector work with your knuckles dragging the ground anyway?
  • 0

#27 Jason Rodriguez

Jason Rodriguez
  • Basic Members
  • PipPipPip
  • 175 posts
  • Cinematographer

Posted 04 June 2008 - 09:19 AM

But why not a 35mm size SI/2K? why didn't you build one in the first place?


Hi Evangelos,

The imaging specs on the Altasens sensor are very good, and it does produce some stunningly good image quality with great dynamic range, color-fidelity, and low-noise. As you've noted, the 35mm DOF issue is one downside of using 2/3" sensors, but compared to anything else on the market, the Altasens sensors are far-and-away the best CMOS sensors that money can currently buy for digital cinema production without starting from complete scratch with all the uncertainties and cost of a new custom sensor design. Obviously as demonstrated by Arri, RED, and others, there are 35mm-sized sensors that can be made, but those are all custom designs. With the SI-2K that was not an option for us.

We actually do have some 35mm-sized sensors in camera heads that we have made, but they are not digital cinema quality.

Thanks,

Jason
  • 0

#28 Jason Rodriguez

Jason Rodriguez
  • Basic Members
  • PipPipPip
  • 175 posts
  • Cinematographer

Posted 04 June 2008 - 09:28 AM

With most linux/bsd distros you can obtain source code and re-compile.


The source code for the drivers we're using is not available. Also since the drivers were designed for Windows, I know simply having the source-code would not make it as easy as a re-compile.

Linux is not being used simply due to lack of drivers for our required hardware. And this is not a "simple" problem. Even for video drivers, Nvidia Detonator drivers are reportedly 15 million lines of code . . . we're talking some very complex stuff here that large companies spend lots of money making sure they are stable on a specific OS platform.

Having to deal with bad drivers is much worse that the fairly petty problems we've encountered with threading on the Windows kernel. For instance, Linux will have kernel panics, and that's the same thing as a Windows blue-screen . . . since we don't have blue-screen issues, I don't see why we would want to trade-away that underlying OS/hardware stability for the perception of a "stable" platform with Linux that due to bad or buggy drivers would be even more prone to actual crashing at the kernel level.

We haven't counted out Linux, and if that platform gains the hardware support we need in the future, then we will definitely entertain development for that platform. But for right now, it's not feasible.

Thanks,

Jason
  • 0

#29 Nate Downes

Nate Downes
  • Basic Members
  • PipPipPipPip
  • 1638 posts
  • Florida, USA

Posted 04 June 2008 - 09:35 AM

The source code for the drivers we're using is not available. Also since the drivers were designed for Windows, I know simply having the source-code would not make it as easy as a re-compile.

Linux is not being used simply due to lack of drivers for our required hardware. And this is not a "simple" problem. Even for video drivers, Nvidia Detonator drivers are reportedly 15 million lines of code . . . we're talking some very complex stuff here that large companies spend lots of money making sure they are stable on a specific OS platform.

Having to deal with bad drivers is much worse that the fairly petty problems we've encountered with threading on the Windows kernel. For instance, Linux will have kernel panics, and that's the same thing as a Windows blue-screen . . . since we don't have blue-screen issues, I don't see why we would want to trade-away that underlying OS/hardware stability for the perception of a "stable" platform with Linux that due to bad or buggy drivers would be even more prone to actual crashing at the kernel level.

We haven't counted out Linux, and if that platform gains the hardware support we need in the future, then we will definitely entertain development for that platform. But for right now, it's not feasible.

Thanks,

Jason

Out of curiosity, what hardware?
  • 0

#30 Jason Rodriguez

Jason Rodriguez
  • Basic Members
  • PipPipPip
  • 175 posts
  • Cinematographer

Posted 04 June 2008 - 03:12 PM

Out of curiosity, what hardware?


The proprietary UDP/IP ethernet protocol we use to make sure that you can get 100MB/s across the gigabit ethernet line with no drop-outs and DMA (so very low CPU usage).

Secondly, the Intel GMA950 doesn't support the ARB_Fragment shader extensions for OpenGL like we need, so we have to use DirectX. A dedicated GPU (i.e, Nvidia) in the SI-2K would consume way too much power.

Thanks,

Jason
  • 0

#31 Nate Downes

Nate Downes
  • Basic Members
  • PipPipPipPip
  • 1638 posts
  • Florida, USA

Posted 04 June 2008 - 04:29 PM

The proprietary UDP/IP ethernet protocol we use to make sure that you can get 100MB/s across the gigabit ethernet line with no drop-outs and DMA (so very low CPU usage).

Not to split hairs, but that's not hardware drivers, just software

Secondly, the Intel GMA950 doesn't support the ARB_Fragment shader extensions for OpenGL like we need, so we have to use DirectX. A dedicated GPU (i.e, Nvidia) in the SI-2K would consume way too much power.

Thanks,

Jason

???

You are making no sense here. Linux offers such extensions, has for years. I can grab a Linux 3D expert for you if you'd like.
  • 0

#32 Nate Downes

Nate Downes
  • Basic Members
  • PipPipPipPip
  • 1638 posts
  • Florida, USA

Posted 04 June 2008 - 04:50 PM

Not to split hairs, but that's not hardware drivers, just software

???

You are making no sense here. Linux offers such extensions, has for years. I can grab a Linux 3D expert for you if you'd like.

Ok, double checked. For the dedicated bandwidth, that's a configutation issue for Linux, and using several of the RT kernels is more than possible. As for ARB_Fragment the support for the GMA950 is late beta in preparedness, talking to my friend. So you are correct in stability.

However, Linux is not the only game in town. Have you ever looked into Solaris, which does support both the ARB_Fragment and the guaranteed bandwidth needs in the embedded environment?
  • 0

#33 Jason Rodriguez

Jason Rodriguez
  • Basic Members
  • PipPipPip
  • 175 posts
  • Cinematographer

Posted 05 June 2008 - 02:12 PM

Hi Nate,

Sorry if this is confusing, but we're not using the TCP/IP stack of Windows, which would mean we also wouldn't use the TCP/IP stack in Linux . . . our cameras involve custom hardware that use a standard gigabit ethernet signal pathwa, but rather than TCP/IP, they are using a custom protocol via UDP/IP on a custom transport layer stack to transmit the signal with DMA support for less than 1% CPU usage.

As for the ARB_Fragment support, yes, Intel has been increasing their support lately for Linux, and by extension for OpenGL in their display drivers, but 2-3 years ago (and back then we had the GMA900) when we started none of this support existed . . . and even then the latest stuff is in "beta" . . .

Suffice to say the Windows kernel is giving us very good stability, and we have the software flexibility to add features and support for some very innovative developments. For instance, is there another camera system on the market that provides full 64-point internal custom user-definable 3D LUT support and film-stock emulation? For 3D-shooting is there a integrated camera system that has the ability liked we previewed at NAB this year that can take two streams and combined them into a single live 3D stereo image? Also how about a camera system that natively shoots to QT and AVI and can be natively ingested (i.e. no proxies or conversions) into two of the most popular NLE's on the market as well as a number of other media-related apps? Add on top of that only 3.5:1 compression and 4:4:4 decoding, basically the equivalent of a HDCAM-SR deck?

There are a lot of great development platforms out there . . . hopefully people can look at the features we're able to offer and see the benefit of the development platform we've chosen.
  • 0

#34 Nate Downes

Nate Downes
  • Basic Members
  • PipPipPipPip
  • 1638 posts
  • Florida, USA

Posted 05 June 2008 - 02:23 PM

Hi Nate,

Sorry if this is confusing, but we're not using the TCP/IP stack of Windows, which would mean we also wouldn't use the TCP/IP stack in Linux . . . our cameras involve custom hardware that use a standard gigabit ethernet signal pathwa, but rather than TCP/IP, they are using a custom protocol via UDP/IP on a custom transport layer stack to transmit the signal with DMA support for less than 1% CPU usage.

As for the ARB_Fragment support, yes, Intel has been increasing their support lately for Linux, and by extension for OpenGL in their display drivers, but 2-3 years ago (and back then we had the GMA900) when we started none of this support existed . . . and even then the latest stuff is in "beta" . . .

Suffice to say the Windows kernel is giving us very good stability, and we have the software flexibility to add features and support for some very innovative developments. For instance, is there another camera system on the market that provides full 64-point internal custom user-definable 3D LUT support and film-stock emulation? For 3D-shooting is there a integrated camera system that has the ability liked we previewed at NAB this year that can take two streams and combined them into a single live 3D stereo image? Also how about a camera system that natively shoots to QT and AVI and can be natively ingested (i.e. no proxies or conversions) into two of the most popular NLE's on the market as well as a number of other media-related apps? Add on top of that only 3.5:1 compression and 4:4:4 decoding, basically the equivalent of a HDCAM-SR deck?

There are a lot of great development platforms out there . . . hopefully people can look at the features we're able to offer and see the benefit of the development platform we've chosen.

I've used several kernels over the years for similar projects and Windows could give stability for us only when there were no other factors, in a completely enclosed environment. Otherwise, I predominantly worked with Linux or QNX's kernel. Now, we were working on some unusual solutions, admittedly, and Windows just could not handle the distribution system at all reliably. This was, admittedly, in '98-'99, but to my knowledge, the NTKRNL has not changed much since then.

I avoid windows development due to the major headaches it gives me, especially the EULA where they can pull your license at the drop of a hat. I, for one, do not like letting another company have that level of control over a product. I have seen companies use that before to kill off competition to their "prized" partners in the past, including with my last computer venture. However, my past is not your past, so I wish you luck and shall keep an eye on things to see how they progress.
  • 0

#35 Peter Moretti

Peter Moretti
  • Sustaining Members
  • 306 posts
  • Other
  • Sherman Oaks, CA

Posted 05 February 2009 - 06:57 AM

Hi Evangelos,

The imaging specs on the Altasens sensor are very good, and it does produce some stunningly good image quality with great dynamic range, color-fidelity, and low-noise. As you've noted, the 35mm DOF issue is one downside of using 2/3" sensors, but compared to anything else on the market, the Altasens sensors are far-and-away the best CMOS sensors that money can currently buy for digital cinema production without starting from complete scratch with all the uncertainties and cost of a new custom sensor design. Obviously as demonstrated by Arri, RED, and others, there are 35mm-sized sensors that can be made, but those are all custom designs. With the SI-2K that was not an option for us.

We actually do have some 35mm-sized sensors in camera heads that we have made, but they are not digital cinema quality.

Thanks,

Jason

Doesn't Dalsa sell their chips?
  • 0


CineLab

Pro 8mm

The Slider

Rig Wheels Passport

rebotnix Technologies

Cinelicious

Aerial Filmworks

Ritter Battery

Visual Products

CineTape

Robert Starling

Paralinx LLC

NIBL

K5600 Lighting

Glidecam

Zylight

Cadrage Directors Viewfinder

Media Blackout - Custom Cables and AKS

Abel Cine

rebotnix Technologies

Cinelicious

Robert Starling

Glidecam

Abel Cine

CineLab

Zylight

Pro 8mm

Rig Wheels Passport

Aerial Filmworks

Paralinx LLC

Media Blackout - Custom Cables and AKS

K5600 Lighting

The Slider

Visual Products

Ritter Battery

NIBL

CineTape

Cadrage Directors Viewfinder