Blackmagic Forum

Since September is coming fast, I might as well anticipate.

While the gamma transforms are available both at the project and OFX level the gamut transform is not available in the OFX.

Still missing in 15.0.1.

Also loading a ProRes Pocket 4k log clip automatically sets the input color space to Rec.709.
It's a bit puzzling to me why this automatic setting of input color space is still lingering.

But having said that, bravo Black Magic!
The footage on the new 4K Pocket looks great and grades well!

It's because what MOV headers say.

Andrew Kolakowski wrote:It's because what MOV headers say.

I would think Resolve should be able to read and interpret this from the metadata:

com.blackmagic-design.camera.cameraType : Blackmagic Pocket Cinema Camera 4K
com.apple.proapps.customgamma : com.blackmagic-design.camera.filmlog

Also, there is no IDT for ACES.

The gamma is close to the BM Film 4.6K but not exactly:

Cary Knoop wrote:

Andrew Kolakowski wrote:It's because what MOV headers say.

I would think Resolve should be able to read and interpret this from the metadata:

com.blackmagic-design.camera.cameraType : Blackmagic Pocket Cinema Camera 4K
com.apple.proapps.customgamma : com.blackmagic-design.camera.filmlog

If they set custom headers then yes, they can and maybe they even should. Problem is that this becomes exception to their current code which reads "colr" atom in MOV headers. From other hadn't this is their own eco system (camera+software), so they know about any change etc. and can easily adjust needed elements.

Andrew Kolakowski wrote:

Cary Knoop wrote:

Andrew Kolakowski wrote:It's because what MOV headers say.

I would think Resolve should be able to read and interpret this from the metadata:

com.blackmagic-design.camera.cameraType : Blackmagic Pocket Cinema Camera 4K
com.apple.proapps.customgamma : com.blackmagic-design.camera.filmlog

If they set custom headers then yes, they can and maybe they even should. Problem is that this becomes exception to their current code which reads "colr" atom in MOV headers. From other hadn't this is their own eco system (camera+software), so they know about any change etc. and can easily adjust needed elements.

One can hardly call it 'current code' as the auto-assignment of clip input colorspace was introduced in release 15. So far it, unfortunately, has been more of a problem than a feature.

If it would work it streamlines the workflow, but it obviously got to work.

Then it's current
Problem is somewhere else. Official flagging spec is outdated, so it has no chance to work well. Another issue is that most apps don't set correct flagging.
BM can make it working well for their cameras as they have full control over all elements.

RCM is supposed to default to the input value in the color management tab, if none is specified for individual clips in the media pool. So you'd expect the default to be "none". But at present it defaults to rec. 709, including clips shot in BDM Film, which must be manually corrected for all clips added to the media pool, for RCM to work.

John Paines wrote:RCM is supposed to default to the input value in the color management tab, if none is specified for individual clips in the media pool. So you'd expect the default to be "none". But at present it defaults to rec. 709, including clips shot in BDM Film, which must be manually corrected for all clips added to the media pool, for RCM to work.

Resolve 15 has this (undocumented?) feature that sets the correct input color space for any given clip. The problem is that it is more wrong than right.

Andrew Kolakowski wrote:Then it's current

True, but I'd venture 'new' would be more appropriate


At any rate, I think BM should get all the above-mentioned issues resolved before the 4K Pocket camera becomes available.

Cary Knoop wrote:

John Paines wrote:RCM is supposed to default to the input value in the color management tab, if none is specified for individual clips in the media pool. So you'd expect the default to be "none". But at present it defaults to rec. 709, including clips shot in BDM Film, which must be manually corrected for all clips added to the media pool, for RCM to work.

Resolve 15 has this (undocumented?) feature that sets the correct input color space for any given clip. The problem is that it is more wrong than right.

Resolve is right. It just follows headers, which are in most cases simply wrong
Maybe there should be setting for default behaviour. Scratch has such a setting to follow or not headers.

Andrew Kolakowski wrote:Resolve is right. It just follows headers, which are in most cases simply wrong
Maybe there should be setting for default behaviour. Scratch has such a setting to follow or not headers.

In some cases the headers are wrong but Resolve 15 has been in error even with correct headers.

For instance, beta versions of Resolve 15 incorrectly set HLG sources (using an mp4 container) to Rec709, this was fixed in later versions.

Past, beta version shouldn't be used as reference.
There was some other bug also with DNxHR in MXF.

Andrew Kolakowski wrote:Past, beta version shouldn't be used as any reference.

No, they should not but you are missing the point of what I was explaining to you.

At any rate, please respond so you can have the last word, I am sorry but I think you are nitpicking and talking semantics, these arguments become rather tiresome.

I get your point, but don't show examples based on old beta which is fixed now.
Show an example of current version where it still reads headers wrong. Then your argument will be valid.

If we are reading headers incorrectly in 15.0.1 for some format i'd like to know details too.

Peter Chamberlain wrote:If we are reading headers incorrectly in 15.0.1 for some format i'd like to know details too.

It's easy to reproduce, just load the "Walking Day" 4K Pocket demo footage in Resolve 15.0.1.
Then check the clip level input color space transform.
It is incorrectly set to Rec709.

Resolve reads only "colr" atom and for Pocket 4K files this is set to Rec.709. It needs small tweak, so for BM cameras it reads extended flagging and ignores "colr" atom headers. It's actually simple rule- if extended flagging found then it overwrites "colr" atom info.

Andrew Kolakowski wrote:Resolve reads only "colr" atom and for Pocket 4K files this is set to Rec.709. It needs small tweak, so for BM cameras it reads extended flagging and ignores "colr" atom headers. It's actually simple rule- if extended flagging found then it overwrites "colr" atom info.

Andrew,

I think Davinci Resolve reads a bit more than the "colr" atom

Code: Select all

com.apple.proapps.manufacturer: Blackmagic Design
com.blackmagic-design.camera.uuid: 299f3a4f-71c1-4182-932e-cbf9f1ea8805
com.blackmagic-design.camera.projectFPS: 23.98
com.apple.proapps.shootingRate: 23.98
com.blackmagic-design.camera.cameraType: Blackmagic Pocket Cinema Camera 4K
com.blackmagic-design.camera.shutterAngl: 180 °
com.blackmagic-design.camera.aperture: f1.9
com.blackmagic-design.camera.iso: 800
com.blackmagic-design.camera.whiteBalanc: 5600
com.blackmagic-design.camera.whiteBalanc: 0
com.apple.proapps.customgamma: com.blackmagic-design.camera.filmlog
com.blackmagic-design.camera.look.LUTNam: Blackmagic 4K Movie to Extended Video.cube
com.blackmagic-design.camera.guides.aspe: 2.40: 1
com.blackmagic-design.camera.guides.safe: 90
com.blackmagic-design.camera.firmware: 0.0
com.apple.proapps.clipID: A003_07200606_C003
com.apple.proapps.reel: 3
com.apple.proapps.scene: 1
com.apple.proapps.shot: 99
com.blackmagic-design.camera.environment: interior
com.blackmagic-design.camera.dayNight: day
com.blackmagic-design.camera.lensFocalLe: 21mm
com.blackmagic-design.camera.lensDistanc: 51945mm
com.apple.proapps.cameraName: A
com.blackmagic-design.camera.colorScienc: Blackmagic 4K Pocket Cinema Camera, Color Science Gen 4


Use the YRGB Color Managed and "Blackmagic Pocket Cinema Camera 4K"
to TL color Space + Color Space Output to your choice

Resolve may import this info, but it doesn't use it and sets input color space purely based on "colr" atom, not those extra info.

Cary Knoop wrote:Also, there is no IDT for ACES.

The gamma is close to the BM Film 4.6K but not exactly...

I found that when I first tried ACES. Tried the 4.6K IDT, but we need one specific to the BMPCC4K.


Sent from my iPhone using Tapatalk

Cary Knoop wrote:Since September is coming fast, I might as well anticipate.

While the gamma transforms are available both at the project and OFX level the gamut transform is not available in the OFX.

The 'Blackmagic Design Pocket 4K Film' gamut transform is still missing from the list of gamut transforms in the OFX control in release 15.1.1. ACES IDT is missing as well.

Also in 15.1.1 the clip level input transform is still set to Rec.709 under YRGB Color Managed.