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

M-X vs M with R3D's...

Patrick, with al due respect, RAW is the RAW electronic signal from the sensor. The only thing that is done to it is a wavelength compression that is not done in the "imaging space", but rather the electronic wavelength space before the data is debayered with appropriate color science into an image. Anyway - the main purpose was to compare the RAW footage from the cameras BEFORE it is touched by some "clever" post guru eliminating the possibility of human "interpretation" of what the data should look like...

No offense to anyone...

Peter
 
Hi Peter,

Firstly thank you for uploading the files, not many people take the trouble so thanks from all us none Red owners at present (like many waiting for fixed scarlet).

I have uploaded a couple of your files, a few glitches to start with eg A111_C0101_0815XX went solid green after about 6 seconds and a half fram corruption on A001_C007_0815V. I take these are the MX sensor, as l noticed a huge difference between A001_C007 and B001_C007 B camera being very dull and lifeless in comparison to A camera.

This is all new to me as l film on an EX1R and with altered gamma curves can give really great shots.

Its all about getting my head around new work flows etc.

Hopefully RED before fixed Scarlet is released will upload proper files from the fixed scarlet so we can all see what the camera can do, not just close ups but panoramic shots as well.

Once again many thanks and back to the work flow.

Andrew
 
thank you for the uploads. I downloaded the R3Ds of the shot of the river, but they crash redcine-x after about 5 seconds. Other R3Ds (from other projects) behave just fine. Any idea why?
 
Maybe you shouldn't zip it?
 
Andrew Salter said:
I have uploaded a couple of your files, a few glitches to start with eg A111_C0101_0815XX went solid green after about 6 seconds and a half fram corruption on A001_C007_0815V. I take these are the MX sensor, as l noticed a huge difference between A001_C007 and B001_C007 B camera being very dull and lifeless in comparison to A camera.
Click to expand...

All the original files are just fine here. It must be either the ZIP-ing or something during the upload/download process. I will quickly upload just the simple R3D of the river shot for both cameras (without the QT proxies, or the folder structure). I will post a link as soon as it is up (its just about 700MB for both files, so it should take less then 10 min...) and then please have a look and let me know...

Cheers,

Peter
 
I have updated all the links with the actual R3D's instead of the ZIP-ed files, as it appears that the ZIP compression generates artifacts in the R3D files themselves. This is something to keep in mind when You are sending R3D's - do not compress them using tools such as ZIP, etc...

Hope this helps...

Peter
 
Pietro Impagliazzo said:
Can you get me ISO 12800 as if it was shot ISO320?
:)
Click to expand...

Well, not that extreme, but if you got an MX sample file I can do a demo for you.

@ Peter

Have you tried to compare the C003 clips?
I found that when boosting ISO to 3200 the M holds more details in the shadows of the rocks, while the MX tends to blur it completely out (compression related blur). That's what I found at least with latest RedCineX build on OSX.
 
Andrew Salter said:
I take these are the MX sensor, as l noticed a huge difference between A001_C007 and B001_C007 B camera being very dull and lifeless in comparison to A camera.
Click to expand...

Andrew. that is because the MX clips are using Redcolor/Redgamma and the M clips are using Redspace/Redspace. You have to change the image (color space & gamma) settings in RedcineX to Redcolor & Redgamma, than those B camera clips get much more lively.
 
Peter Majtan said:
I have updated all the links with the actual R3D's instead of the ZIP-ed files, as it appears that the ZIP compression generates artifacts in the R3D files themselves. This is something to keep in mind when You are sending R3D's - do not compress them using tools such as ZIP, etc...

Hope this helps...

Peter
Click to expand...


This would seem highly unlikely. ZIP compression is mathematiacally lossless...

-sc
 
Peter Majtan said:
Patrick, with al due respect, RAW is the RAW electronic signal from the sensor. The only thing that is done to it is a wavelength compression that is not done in the "imaging space", but rather the electronic wavelength space before the data is debayered with appropriate color science into an image. Anyway - the main purpose was to compare the RAW footage from the cameras BEFORE it is touched by some "clever" post guru eliminating the possibility of human "interpretation" of what the data should look like...

No offense to anyone...

Peter
Click to expand...

Hi Peter,

If that were true black shading would not be important & there would have been Zero improvements due to firmware updates.

No offence ti anyone
 
Stephen Williams said:
Hi Peter,

If that were true black shading would not be important & there would have been Zero improvements due to firmware updates.

No offence ti anyone
Click to expand...

Black-shading reads the electronic noise characteristics inherited with every sensor and simply filters out this noise when it reads the electronic signal. The firmware updates are mainly for added functionality to the UI, improved read-reset performance, etc... - it has pretty much no impact on the actual RAW data as far as image is concerned - which is why You can open "old" R3D's with "new" color science and you get a much better image that looks like shot on the latest build...

Putting all this aside - You are missing the MAIN point here. When people post-process the RAW data into a images for "comparisons" - inevitably You are introducing a "human element" into the comparison. If You then see the comparison in "video" format - it is hard to understand what was done to the footage. The purpose here is to provide the RAW data from the camera - so you all can do the comparison Yourselves under Your controlled conditions...

If You can't "see" that - I rest my case...

Peter
 
Robert Niessner said:
Have you tried to compare the C003 clips?
I found that when boosting ISO to 3200 the M holds more details in the shadows of the rocks, while the MX tends to blur it completely out (compression related blur). That's what I found at least with latest RedCineX build on OSX.
Click to expand...

I did - but this is an optical illusion. The noise makes You believe that there are more details. You can actually add noise in Photoshop (Add Noise - Monochrome - Level 5) and You will see what I mean. But if You look closely at the darkest areas - You will see how much more detail there is in the MX footage:

M:
B001_C003.jpg


MX:
A001_C003.jpg


Here is the MX shot with Add Noise Level 5 Mono in Photoshop:

A001_C003n5.jpg


Noise greatly helps with perception of sharpness/details, but this is only optical illusion...

Cheers,

Peter
 
Steven Caesare said:
This would seem highly unlikely. ZIP compression is mathematiacally lossless...

-sc
Click to expand...

Then there must be something wrong with it's "mathematics"...
There must be something about the R3D RAW data structure that conflicts with the ZIP-ing algorithm (on the ZIP engine part, not the R3D itself...)

Peter
 
I fyou pull an MD5 hash on the file going in to the zip and coming back out and it's changed, then you have a broken .ZIP utility...

-sc
 
You must log in or register to reply here.
Back
Top