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 :)

Intel's new Core-i7, big impacts on performance

mdharrington said:
ok...
question about going from Red/SDK rgb...to Cineform Raw through back sampling...or really remosaicing(did I just invent a word?)

as far as I can tell...mathematically in an ideal situation there would be no loss of quality....

correct me if I'm wrong of course...I may be overlooking something

If the bayer pattern is known....and I assume it is....
Then a bayer pixel would be known to be either R,B,or G
If a bayer pixel is known to be G....and the developed image(demosaiced) contains anything other than G....then the resulting R and B values can be discarded....Since this is an RGB Raw sampling to begin with, the other color values should not affect luminance...the way YUV would.

the same would also hold true for the Blue and Red bayer pixels as well.Each known pixel...(known as in there position and color filtering on the bayer sensor) would have the other 2 non native color channels discarded.
Being that seperate channels are recorded for each value this should be simple.

Some caveats....
1.If the bayer pattern is unknown(how many are there really?) then this is assumption
2.If there is some baked in sharpening ect ect that would be anything but the Raw RGB
3.If the origional debayering gave a pixel....green for example....more or less green then was natively recorded due to it's neighbouring pixels via some color weighting algorithm

If these are all not factors, and unless I'm missing something(quite possible) then the mathematics of remosaicing is quite simple, and should be mathematically perfect. At least the remosaic part.

The algorithm that would again demosaic it, of course would be different...and could lead to different results
Click to expand...

Remosaicing? Cinemaphotographers would do that...?

I think your observations are correct, matching my own.

I did some deBayer algorythms my own in the past. The starting point was always a native RGB image (source was 3 colored per pixel and downsampled to gain "correctness" of averaged color per pixel). The I stripped off two color components per pixel on a Bayer pattern style like

R G
G B

Basically a Bayer pattern is always 2 green, 1 red and 1 blue pixel, where green is diagonal, and red and blue on the free corners. You can rotate or mirror that pattern, but essentially there is not much options.

Clearly its helpful to know the pattern of the camera to do what David does with Cineform tools now.

My tests for the algorythms where always to compare the deBayered image (from the artifical Bayer image) with the original source RGB image (from which the artigicial Bayer image was derived). The closer I get, the better the algorythm.

Clearly there is often more involved that resampling the missing color pixels. When coming from a sensor, the RAW data needs to be adjusted for certain artefacts, like:

1. black noise level (the values the "photosite" recognizes without any light being received at all)
2. individual pixel gamma/gain noise (technically you can have a 1D-LUT per pixel/photosite to make it perfect)
3. color cross talk (done by using matrix computations etc.)

In a perfect world the above artefacts would be resolved PRIOR to storing the RAW file, making it a perfact RAW file - as this kind of corrections only relate to "failures" of the sensor not returning the perfect image. Every sensor has some differences, this is why we need to do black shading for instance. Point #2 is not very likely to happen on most cameras, as its exessively computing intensive. The Drake camera did that, though... - their images were so good that even the vendors of the sensor couldn't believe it.

4. sharpening
5. any kind of "intelligent" deBayering etc.

4 and 5 I'd prefer not to baked into the RAW (and RED seems to feel the same :))

There may be more to do, thats just what I have in mind right now.

So basically - if the deBayer algorythm keeps the real pixel values of the Bayer pattern pixels unchanged, going back from RGB to RAW and back to RGB should not change the image in ANY way, except you used a different algorythm.

The biggest point IMHO is color cross talk / matrix computation. If that is not included in the RAW itself, it could become tricky... But as the RED RGB includes it for sure, the approach David is showing feels pretty OK to me. And in the end, David did it for the time being until RED gives us all the desired RAW access via SDK.

I hope their developers find some time between the many new stuff on their roadmap, to implement this basic feature. It is hopefully not to far away, as it must be inside their code anyway (how else would they extract RGB otherwise from it). Its just that they should allow to skip the RED deBayer and provide access to a 12 bit "grayscale" Bayer pattering bitmap after decoding their RED CODE compression. The last is clearly something that belongs to their SDK, but the deBayer step should be open.

I'd like to repeat that if RED is hesitating to release RAW access for not being sure about being judged correctly on the final image quality if other deBayer methods are used, then all it requires would be to make it a must of any SDK licensee to include an option (beside own deBayer methods) to use the RED SDK deBayer method.

I believe many companies would use RED SDK for rendering, while doing their own stuff for realtime editing / grading / processing of any kind. It would be a workflow advantage IMHO.

But back to speed, beside the (always uncomfortable) transcoding times, Davids approach is very potentially giving us lots of speed in the post production.

I need to call him :)


Axel
 
good points Axel....

I naturally thought that a remosaic image would have a lot of artifacting like doing double compression on an image....until I really examined how it would have to be done

could you expand on what you mean by color cross talk....
is this a voltage leakage thing across photosites?
 
I am not really an expert on this, but it is what I understood from it so far:

Color cross talk

Each photosite is responsive not to a single color, but to a bandwidth of light ranging from x nanometers wavelength to y nanometers. For each specific wavelength it has a different sensitivity, resulting in a curve, where x-axis is the wavelength and y-axis the sensitivity to the specific wave length.

The three curves for r, g and b overlap. Technically ideal would be three rectangular "curves" that do not overlap, but leave no gaps. Thats physically currently not possible (maybe it will never be possible, not to say likely...). So each curve looks like a mountain, and three mountains r, g and b sensitivity overlap somewhat. That is were color cross talk can take place, as two differently filtered photosites see values coming in that define a color. Its not exactly the same as mixing r, g and b to a new color, but it means you may not be able to expose a pure green without e.g. exposing somewhat r or b as well. It happens on film as well. The better the separation, the better is your color reproduction.

The matrix allows you to mix the measured values into new values like this:

r new = n1*r + n2*g + n3*b
g new = n4*r + n5*g + n6*b
b new = n7*r + n8*g + n9*b

More or less like this...

Axel
 
What we have to have in mind is following:

Going back from decoded R3D RGB to Cineform RAW means using a wavelet compression scheme on the Bayer quadrants again. THAT can introduce differences and artefacts. But essentially no more than going from R3D RAW to Cineform RAW directly, as explained above. Creating a RAW from the RGB should result in the same as converting the RAW into RAW, as the RGB should contain the untouched RAW info.

Axel
 
BTW, here's a nice little test to compare the two images:

This is a split screen test at 300% pixel-for-pixel zoom in Photoshop . . . one-side is CineForm RAW demosaiced from the original R3D file, and other side is the original R3D file taken from these images here:

http://www.reduser.net/forum/showpost.php?p=331665&postcount=14

I'm not telling you which side is which, and I'm not lot saying exactly where the split point is, although I will say it's not 50/50, but it's not more than a 40/60 split between the two (i.e., this isn't a trick and one format is a sliver at the edge).

So, which side is which, and which side is "softer" than the other?

Split-Screen.PNG


While not scientifically accurate because we're working with JPEG's (this image is an uncompressed PNG created from the original JPEG's though, so no additional compression has been applied), I think this visually proves that the information encoded in the CineForm RAW files is equally as good for all intents and purposes as the original R3D file.

Thanks,

Jason
 
BTW, the above post was not meant to send the topic off thread . . . so my intent is not to fill up the rest of the replies with responses to this "test" . . . I merely wanted to visually show that the results of CineForm RAW recoded from a R3D file is pretty much visually indistinguishable from the original.

Thanks,

Jason
 
axel...

i get the cross talk now...I forgot how it worked
so a photosite then is not pure RGB.... but a mix based on the cross talk...
but like you said that should be solved before it's encoded...even Raw..

so the Raw encoding is still only recording a single color value per photosite...just not 100%physically accurate...shouldn't effect back sampling at all
 
Jason,

interesting comparison. Hard to say where the boarder is. I do think it could be little left from the center. I think I can see kind of a vertical "boarder" artefact in the rubber, lower left from the wheel maker name. But I can be wrong :)

Axel
 
I guess I needed to start a thread on back sampling RAW. Jason, thank you, that was the test I was hoping users would try. Once users confirm for all practical purposes RAW is the same as 4:4:4, workflow advantages favor RAW.
 
David Newman said:
I guess I needed to start a thread on back sampling RAW. Jason, thank you, that was the test I was hoping users would try. Once users confirm for all practical purposes RAW is the same as 4:4:4, workflow advantages favor RAW.
Click to expand...

Just because you show one image that has almost no high frequency detail doesn't mean it's a conclusion. Side by side is bad way to evaluate this kind of thing. When you look at them overlaid, there is a definite loss of sharpness that you then have to overcompensate by adding more sharpness which ends up looking worse.

As with anything like this you have to look at many different types of images to properly evaluate. A single not so sharp image of a tire doesn't qualify.
 
You second argument discounts your first, you have made an conclusion from one image, which I neither agree with your analysis, nor do I find it all that riguous (to you second point.) We have done many, many images, so I speak from that confidence, but we encourage people to try it for themselves, isn't that better than reading either your or my claims on quality. The balance of sharpness to noise supression, is a range in either demosaic, for any camera, as I'm sure you know. So let say one is slighly softer, it is also slightly less noisy, which the nature of the demosaic algorithm. If you adjust them to the same sharpness, they will have the same noise level, so it is a wash (as it should be.) They the same source, the techniques are not adding noise, all noise is that native to the source. So in the end is about the workflow advantages, if you don't want them, or you don't see the value for your production needs, don't use them, but don't discount these advantages to others.
 
Jason Rodriguez said:
...I think this visually proves that the information encoded in the CineForm RAW files is equally as good for all intents and purposes as the original R3D file.
Click to expand...

!!! Disclaimer - I am not trying to denigrate CineForm at all. I have not personally done enough tests to make a judgment call !!!

But Jason - come on... really? :)

I can see the line clear as day, and both sides are crappy. This is a miserable test image... and I know that you are waaaay smarter than this and can figure out a much better way to show an image quality comparison. :)

This is sort of like posting two wildly out of focus underexposed images and saying, "See... LensA is just as good as LensB!"

Lucas
 
agreed...
we need some better test images...
 
Yes, not a great source, but so many of my good sources I don't have clearance for (I did the extreme windowing this one, as I didn't have clearance for it either.) Happy to post the result for any R3Ds others can provide, and anyone can do their own tests. Good or bad, that is a R3D clip, are we not arguing that they a mathematically the same but the difference is subtle enough not to impact workflow, and neither workflow is better than the other when it comes to quality.

P.S. If I'm provided with a new clip that others prefer, I'll start a new thread with a more accurate topic. Note: I could use OpenCut 1.0 footage (CC licensed) but then people would complain it was build 12 (or 9), i.e. old. So Build 16+ only please.
 
I understand the math also, and that demosaicing refinements that can impact reversiblity, but practicularly this is not come up as an issue when you consider the workflow. Compression using itself, whether CineForm's or REDCODE is not mathemathically reversible, subtle compromises are made for greater strides in the workflow -- if Red captured only uncompressed, there will be a little higher quality images, but maybe only 1% the number of users (a good workflow trade-off.) It is with this understanding what we offer the back sampling for the huge workflow advantage (with no practical impact on quality.) Remember we want true RAW access, but not the reasons the RGB to RAW back sampling may or may not be mathemathically reversible for all bayer filters, rather that it is a waste of CPU cycles to develop to 444 in the first place. If you going with RAW, you want it for speed, just as if REDCODE was internally stored as 4:4:4 4K, it would be three times slow than it is today. This is why RAW is such a useful format, it effectively stores larger spatial information it significantly lower data rates, it is a compromise in the first place (in camera) but a damn good one.
 
Hey David,

Having just purchased a beloved XW8600 dual 5460 Workstation for my future Cineform purchase.... should I be selling this HP fast on Ebay and gearing up for a single core i7 system like tomorrow???

I'd hate to think my XDUAL CORE QUAD W8600 is already slower than a single core i7!!!!

Any advice please?! Thanks!!!
 
That is a tough one, as you will lose money on your HP sale, but likely get some change on a Core-i7 extreme edition. However the reliability and expandability on that HP xw8600 is incredible, and we don't have that equivalent build quality in an i7 system yet (that will be HP again.) We have 4 or 5 xw8600s at the office, and the all have run perfectly for the year we had them. I would likely stick with the xw8600 if is a primary workstation, add an i7 or two later on for a fast render farm. I have both in my office (and my office is light-er on CPUs, CineForm has more CPU horse power per head then any other company I know,) I'm still using my xw8600 as my primarily developement system.
 
I'm waiting for the Xeon/server level Core i7 mac pro's to be released in January :)



Imagine the performance boost then?
 
Jason,

Dispite people's critisim, I am grateful for the intention behind your test. While I am sure it could have been done differently, you get kudos for actually DOING something.

Reality, with your incredible visual talents and abilies I'm surprised you completely missed the RED discussion forum section on using your REAL name. That way we can see some of the incredible projects you have worked on. Until then, your posts don't really deserve any reply since we have no idea who's doing the posting.

It's been my experience that 20 year professionals tend to be a bit more.... Polite. As least the successful ones. Something about not knowing where your next job is coming from. I can tell you I have been hired by 12 different people on here.

Jay A Kelley
www.dreamwelder.com
 
You must log in or register to reply here.
Back
Top