Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

myriad of questions...

S

sakalli

Member
Joined
Sep 4, 2007
Messages
9
Reaction score
0
Points
0
hi all,

quite new here. trying to understand this beast, so a few technically oriented questions (some slightly off topic though). apologies if they have already been covered, did search the posts but maybe not well enough.

debayering:
does the bayer pattern in practice not amount to 422 footage in any case even if the signal is 444 after debayering? are there not twice as many green pixels than blue and red? i appreciate that the process of arriving to the image is different than the 422 colour sampling scheme and might result in a different look but and that by staying with rgb is advanteous to yuv, but pixel wise, for keying etc, is it not comparable to 422. isnt the resolution of the greenscreen 2K and not 4?

rgb
redcode raw is rgb colorspace right? which would be a good thing. one less colorspace conversion, more information whilst manipulating in post. yuv or y'crcb is a sort of compression as well, no? am i getting this right?

fcp workflow:
there are two recommended work flows for red using (according to teds presentation and also the demo in the red stand at ibc). one is for film out and 4K, keeping the material as redcode raw and editing with partially decoded footage in fcp. the other one, for all other purposes, is to convert to prores during ingestion if outputting to hd sd etc.

what are the drawbacks of not converting to prores. no footage manipulation, effects etc while working with partially decoded redcode raw? the advantages would be at least these: one less conversion (also rather long one), staying with native format (= more or less same as first point) and less disk space.

also just out of curiosity what are the technical hurdles for implementing redcode raw native editing in fcp. no support for 12 bit RGB nor 4K? other? colorspace issues? fcp does support rgb and yuv 10 bit but not sure what bit depth the rgb is. and weather it really supports these colorspaces?

dust on sensor
how big of a problem is dust on sensor. and what does it mean to clean it? what would it cost to repair a damaged sensor? 3 chip cameras with their disadvantages have the advantage that sensor doesnt get dusty as they are protected by the prisms which are less sensitive to clean. also dust on the class is not in focus whilst obviously on the sensor it is.

i know i know. many questions. but would still appreciate any responses, links or corrections.
 
Output of the demosaicing is very high quality. Depending on the image content, the resolution of the chroma can be the same as or lower than the luma. You can't use descriptors such as 4:2:2 or 4:4:4 as they are only suited to video not raw. The end result is, not to worry as the image is superb, very much like that from a high end DSLR. When we demosaic we demosaic to full RGB at 16bit depth (from 12bit data, to keep precision).

Resolution of the green / luma is only limited by that of the optical anti-alias filter. You should not want it to be any other way as aliases will kill image quality and ability to key.

YCbCr is not evil - it's just another space. It's only when you don't have enough precision that there's an issue. It's not compression, but it allows for 4:2:2 compression etc.

You'll never get dust on the sensor as it's sealed and protected by the IR / optical low pass filter. It's that that you clean, and it's easy - a sensor brush and air blower. It's far from the sensor to throw any dust out of focus.

Graeme
 
Yes, linear - image must be linear before it hits the matrix. OpenEXR - in the future perhaps, but for now, we're helping people through the 10bit DPX route as that's most common for DI workflows.

As for other demosaic? Perhaps.

Graeme
 
Just out of my curiousity

Why DPX and not CIN (Cineon) ?
 
DPX is preferred. it has more room for standardized metadata I think.

Graeme
 
sakalli said:
debayering:
does the bayer pattern in practice not amount to 422 footage in any case even if the signal is 444 after debayering? are there not twice as many green pixels than blue and red? i appreciate that the process of arriving to the image is different than the 422 colour sampling scheme and might result in a different look but and that by staying with rgb is advanteous to yuv, but pixel wise, for keying etc, is it not comparable to 422. isnt the resolution of the greenscreen 2K and not 4?
Click to expand...

Hey sakalli, welcome!

Comparing debayering to 4:2:2 sampling is difficult, the short answer is because of the spacial relationship between the color samples in the pattern it is possible for very smart algorithms to create very sharp RGB images from a Bayer pattern. I started an article trying to explain what I know about Debayering, you can read it here:

http://www.redhax.net/wiki/Bayer_Demosaicing

IBloom
 
Let me just add (I finally found a way to say this) the reason bayer pattern is very different from 4:2:2 YCbCr is because there is an inherent relationship between the three channels that can be exploited during the debayering process. In 4:2:2 the channels are completely independant of one another. Is this helpful??
 
Rivai said:
Just out of my curiousity

Why DPX and not CIN (Cineon) ?
Click to expand...

Also because DPX is a standarized file format as opposed to being a Kodak created/controlled format.
 
im.thatoneguy said:
Also because DPX is a standarized file format as opposed to being a Kodak created/controlled format.
Click to expand...

Nobody uses Cineon anymore because there is no standard place in the file format to insert information like time code and keycode. DPX was designed as an extended Cineon format that could also house other metadata. Nearly all conforming software today relies on time code and keycode information contained in DPX headers to identify frames. There are manufacturers also putting other information in those headers: LUT's, camera information, and even digital sound are some of them.
 
im.thatoneguy said:
Also because DPX is a standarized file format as opposed to being a Kodak created/controlled format.
Click to expand...

Just fyi - DPX *is* Cineon, but with a section in the file for extended metadata. But the image essence in a DPX is exactly (bit for bit) the same as a Cineon file.

Almost all DI programs will recognize a CIN as DPX if you rename the extension...

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA
 
mmost said:
There are manufacturers also putting other information in those headers: LUT's, camera information, and even digital sound are some of them.
Click to expand...

The downside is that even fewer dpx readers will be able to do anything with the nonstandard data in the userdata section.


Deanan
 
Deanan said:
The downside is that even fewer dpx readers will be able to do anything with the nonstandard data in the userdata section.
Click to expand...

Hence why there are groups (ASC, SMPTE, other standards organizations) trying to standardize it. But for the moment, even without standardization, there are some good uses for it in closed workflow environments where the additional data can and is used for all of the things I mentioned.
 
luki said:
Just fyi - DPX *is* Cineon, but with a section in the file for extended metadata. But the image essence in a DPX is exactly (bit for bit) the same as a Cineon file.
Click to expand...

My point was it would take the SMPTE review process to change said file definition as opposed to Kodak waking up one day and deciding to rewrite it. People like dependability even if it's just a "standardized" red rubber stamp on an existing product.
 
Usually the market figures out what the right approach is (by itself) and then SMPTE comes in later to 'officially' standardize it.

2- I don't think people put much weight on the SMPTE "stamp of approval" nowadays... especially when "standard" formats (e.g. MXF, DPX) aren't always compatible.

Though I think MXF is a good idea so you aren't tied down to proprietary frameworks... namely Quicktime and its color management bugs. Which is a problem Red has to deal with.
 
MXF is just a wrapper though, and Quicktime bugs are as much the codecs as the wrapper itself. MXF fails to learn from the big problem of Quicktime - both are hideously complex :-)

Graeme
 
i've come across Avid MXF, Panasonic MXF and Sony MXF clips and they each appear to be proprietary ...
 
You must log in or register to reply here.
Back
Top