Format thought...

[Peter Majtan]

Basically we have (so far) three cameras:

RO - Red One
RS - Red Scarlet
RE - Red Epic

Then we have (so far) three sensors:

mo - Mysterium "Original"
mx - Mysterium "X"
mm - Mysterium "Monstro"

Then we have (so far) six different sizes (from smallest to biggest):

23F - 2/3" Fixed (Great suggestion by Michael. I originaly proposed "FIX", but 23F makes more sense...)
23I - 2/3" Interchangeable (You can't have "/" in a name for computer syntax reasons)
S35 - Super 35
F35 - Full-frame 35
645 - Medium Format (EPIC 9K)
617 - Medium Panoramic Format (EPIC 28K)

Then there is the RED CODE "quality" level:

rc028 - Current RED ONE RC-28
rc036 - Current RED ONE RC-36
rc042 - Proposed Scarlet 2/3"
rc080 - Proposed Scarlet S35
rc100 - Proposed Scarlet F35
rc225 - Proposed Epic S35/F35/645
rc250 - Proposed Epic X
rc500 - Proposed Epic 617

Instead of including "K" resolution and aspect ratio I would rather recommend using the actual pixel info:

4096x2048 - instead of 4K - 2:1

This would prevent issues with ".x K" formats, such as 4.5K and various ways to write ratio (1.33 vs 4:3), and it would be beyond any confusion for everyone...

So in summary we could have Meta Data header with:

ROmoS35rc036-4096x2048
(Red One with original Mysterium, S35 with Red Code 36 and 4K in 2:1)

RSmmF35rc100-5120x2560
(Red Scarlet, Mysterium Monstro, FF35, Red Code 100 and 5K in 2:1)

etc...

It looks awkward, but it is clear, consistent and future-proof...

Peter

 

[Joseph Ward]

All this has to do is with Lens Coverage. Just say what is lens coverage that can fit for max sensor usage.

 

[Gavin Greenwalt]

But peter through all of that you still didnt list the most important piece of information:
Size of the sensor.

You have to know the exact dimensions (and max resolution) to know the horizontal aperture of the shot. That's a lot of 'look up knowledge' that isn't included in the meta-data.

I would say that meta-data is an example of lots of data, but little knowledge. It doesn't matter what body shot it, the only thing that matters is the sensor used (if you care about dr etc). It doesn't matter what size the sensor is if you didn't use the whole sensor.

'gate width' and sensor type are the only two pieces of information at all relevant that don't already exist innately within the image header. Resolution, Framerate and Codec are all intrinsic to the file anyway.

 

[Pietro Impagliazzo]

But peter through all of that you still didnt list the most important piece of information:
Size of the sensor.

You have to know the exact dimensions (and max resolution) to know the horizontal aperture of the shot. That's a lot of 'look up knowledge' that isn't included in the meta-data.

I would say that meta-data is an example of lots of data, but little knowledge. It doesn't matter what body shot it, the only thing that matters is the sensor used (if you care about dr etc). It doesn't matter what size the sensor is if you didn't use the whole sensor.

'gate width' and sensor type are the only two pieces of information at all relevant that don't already exist innately within the image header. Resolution, Framerate and Codec are all intrinsic to the file anyway.

So, do you think it's a good idea for RED to include these informations on the metadata?

New cameras would get this from the get go and R1 would get it on a new build.

 

[Dave Weber]

to :beatdeadhorse: or not to :beatdeadhorse:

What was the question?

 

[Peter Rollins]

to :beatdeadhorse: Or not to :beatdeadhorse:

What was the question?

buwahahahahahah

 

[Brook Willard]

Let's see if we can't find a way to overcomplicate this...

 

[david farland]

Wow.....

These are the conversations that will most likely happen.........

"I shot it at 2K on a RedOne".
"I shot it at 4K on a Red..16x9...etc"
"I shot it at 4k and outputed to 1080p..16x9...etc"

In near(ish future)
"I shot it at 4K on an Redone, Epic..16x9...etc"
"I shot it at 5K on an Epic..16x9...etc"

In 2 years
"I shot it on a Red 6K..16x9...etc"
"I shot it at 5K on a Red monstro....16x9, etc"

If you mask the sensor image for whatever reason i.e lens, crop, what ever.....that's your stated resolution....pretty simple.

Dave

 

[Gavin Greenwalt]

So, do you think it's a good idea for RED to include these informations on the metadata?

New cameras would get this from the get go and R1 would get it on a new build.

We can include the current US president at the time of the shoot in meta data. There's plenty of space.

I'm just saying. It's not terribly useful. What would be useful is the cropped chip dimensions in the meta-data so that the user doesn't have to do the math themselves based on research online.

"Well this shot is 3291x1731 that means... since it was shot on a Monstro... carry the 3... divide by 36... take the third derivative...."

Including sensor type etc is just dancing around the number someone is probably trying to determine: the size of the sensor.

 

[Humberto Rivera]

Ff35

Ff35

The FF35 has two sets of lenses, first the three zoom and one 300mm lenses that have been announced for the FF35 camera, and the seven new Arri Compact Primes that range from 18mm to 85mm. Both sets of lenses fit well within the 36mm X 24mm diagonal circle of 44mm. The Arri Compact Primes range in between “T1.5 and T3.6”, but they are not the same quality as the Arri Master Pimes.

You would be having two stops of faster speed, and only have to change the brain between the S35 Mysterium –x sensor, and the FF35 Mysterium Monstro Sensor, everything else remains the same.

That’s after the S35 Mysterium –x sensor comes out first, so we have some time to wait, but at least we know what comes after, the FF35!

Humberto Rivera

 

[david farland]

617 - Medium Panoramic Format (EPIC 28K)

Then there is the RED CODE "quality" level:

rc028 - Current RED ONE RC-28
rc036 - Current RED ONE RC-36
rc042 - Proposed Scarlet 2/3"
rc080 - Proposed Scarlet S35
rc100 - Proposed Scarlet F35
rc225 - Proposed Epic S35/F35/645
rc250 - Proposed Epic X
rc500 - Proposed Epic 617

This isn't really a quality indicator.

rc100 is in MB/sec....and it's there to accommodate max fps ( & pixel count ) and of course we don't know if it's always scanning the full sensor. Actual compression will be higher on 645 than Redone than FF35 than S35

D

 

[Peter Majtan]

But peter through all of that you still didnt list the most important piece of information:
Size of the sensor.

You have to know the exact dimensions (and max resolution) to know the horizontal aperture of the shot. That's a lot of 'look up knowledge' that isn't included in the meta-data.

I would say that meta-data is an example of lots of data, but little knowledge. It doesn't matter what body shot it, the only thing that matters is the sensor used (if you care about dr etc). It doesn't matter what size the sensor is if you didn't use the whole sensor.

'gate width' and sensor type are the only two pieces of information at all relevant that don't already exist innately within the image header. Resolution, Framerate and Codec are all intrinsic to the file anyway.

Since the size of the sensor is one thing and the actual exposed area is another, that info is actually included in the "META" header. Since each of the sensors have a given pixel pitch, any RED and 3-rd party SW could easily display the actual size of the sensor area that was exposed.

Take the example above: RSmmF35rc100-5120x2560

It tells You (and the SW) that RED Scarlet Mysterium Monstro with FF35 size was used. Once released we will know the exact pixel width/pitch and this will be then multiplied by the pixel resolution X=5120 x PPx and Y=2560 x PPy, where the PPx and PPy are the respective pixel pitches for X and Y directions (assuming their are not squared). This will be even simpler if the PP is identical for both X and Y (squared photo sites)...

So that info is indeed included in the META...

Peter

 

[Peter Majtan]

This isn't really a quality indicator.

rc100 is in MB/sec....and it's there to accommodate max fps ( & pixel count ) and of course we don't know if it's always scanning the full sensor. Actual compression will be higher on 645 than Redone than FF35 than S35

D

Jim actually stated the contrary. For the RC-28 and RC-36 this was indeed the case, but for the newer ones this is no longer the case. The new numbers were to indicate a "quality improvement" over the previous generation and not the actual bit rate (in MB/s)...

Peter

 

[Rocco Schult]

I believe yes and no - yes, I remember too, that the 617 would have a relatively higher compression and no, the new numbers do not equal MB/s.

 

[david farland]

Jim actually stated the contrary. For the RC-28 and RC-36 this was indeed the case, but for the newer ones this is no longer the case.
The new numbers were to indicate a "quality improvement" over the previous generation and not the actual bit rate (in MB/s)...

Peter

Not sure what your actually stating but as I said greater data rates are required for more pixel/fps.
So whatever scale you use (Jim say it's better or data rate) there no absolute external value particularly when the compression ratios change with fps.
D

 

[Peter Majtan]

David, with all due respect, all I am saying is that I clearly remember Jim posting a clarification about the RED Code number naming. While for the current RC28 an RC36 the numbers indeed relate to MB/s, this is not the case for the upcoming codecs. The new numbers are meant to approximate the "quality improvement" over the existing codecs, rather then actual MB/s data rate. So, if I understand it correctly, a RC100 should have almost 4x the quality of RC28. I will try to look for his post, I believe it was on SCARLET USER...

Peter

 

[Steve Sanacore]

In my humble opinion that won't really help the problem that originally started this discussion, which was people not realizing that '5K' and the like don't tell you anything about physical sensor size or shape and starting to say things like "does this lens cover 5K" a lot. Not that I have a better idea.

That said though it's a good idea for identifying footage/shoot types, people ought to use it on their slates!

If you only need to know format size, then FF35, S35, 2/3 etc is all you need to know as far as what optics will work with what format. The megapixels are irrelevant. If on the other hand we want to know the file format then 2K, 3K, 4K, 5K, 1080P etc. is all we need to know.

I guess we could then combine the two as, "FF35-5K" for example.

 

[Gavin Greenwalt]

David, with all due respect, all I am saying is that I clearly remember Jim posting a clarification about the RED Code number naming. While for the current RC28 an RC36 the numbers indeed relate to MB/s, this is not the case for the upcoming codecs. The new numbers are meant to approximate the "quality improvement" over the existing codecs, rather then actual MB/s data rate. So, if I understand it correctly, a RC100 should have almost 4x the quality of RC28. I will try to look for his post, I believe it was on SCARLET USER...

Peter

Maybe for RC23 to RC36. But it looks like the next generation is going to be based on resolution not quality. Now you certainly get a more efficient codec so MB for MB RC200 will be more efficient than RC100. But the increased bandwidth is largely due to increased resolution not a reduction in compression.

All Jim said before was that the numbers are no longer linked directly to MB/s. (He was answering my question about how we were supposed to record 100MBs) So RC100 won't be 100MBs but that doesn't implicitely prove that RC200 will be the same bandwidth.

It's the old "Mike likes bread. Dogs like bread. Therefore Mike is a Dog" incorrect proof.

 

[JanneJansson]

When referencing how footage was shot, how about this?

RED ONE, 4K, 24fps (with a Cooke 50mm S4).
EPIC-X, 5K, 24fps (with a 35mm RPP).
EPIC-M, 6K, 24fps (with a 100mm RPP).
Scarlet 2/3 3K, 100fps (with an 8mm MRP- miniRED Prime).
Scarlet-F, 3K, 24fps.
EPIC-645... etc.

Or with PPMM pixels per millimeter

4K @ 24 fps @ 115 ppmm
4K @ 24 fps @ 73 ppmm (larger sensor, but same resolution is lower pixel density)

 

[Peter Majtan]

Maybe for RC23 to RC36. But it looks like the next generation is going to be based on resolution not quality. Now you certainly get a more efficient codec so MB for MB RC200 will be more efficient than RC100. But the increased bandwidth is largely due to increased resolution not a reduction in compression.

All Jim said before was that the numbers are no longer linked directly to MB/s. (He was answering my question about how we were supposed to record 100MBs) So RC100 won't be 100MBs but that doesn't implicitely prove that RC200 will be the same bandwidth.

It's the old "Mike likes bread. Dogs like bread. Therefore Mike is a Dog" incorrect proof.

Gavin, I am not exactly sure to what You are referring to... In no way I have ever mentioned that the bandwidth would be the same between various RC codecs. All I was saying was that the number in the codec name will no longer correspond to MB/s data rate as we were used to with RC28 and RC36. Feel free to point out if (and where) I did so...

Peter

EDIT: My comments were in response to David's statement where he said that (in relation to RC naming): "This isn't really a quality indicator. rc100 is in MB/sec..."
Just as You and therock stated - I was confirming that the RC number does not relate to the MB/s. Nothing more, nothing less...