Pixel format for Canon R5 CLOG3 10-bit Footage? (8-bit vs 32-bit)

MarkAnthony121 wrote on 2/17/2022, 12:38 AM

Do I need to set my project to 32-bit floating point if I'm working with 10-bit Canon R5 CLOG3 10-bit footage? Or leave it 8-bit? Because when I choose that with 10-bit footage on my timeline the image turns green, stretched and pixelated, like a bad tube TV image lol.

Comments

Yelandkeil wrote on 2/17/2022, 1:26 AM

Is there any logical interrelation btween these two?

I mean the floating point and green image.

-- Hard&Software for 5.1RealHDR10 --

ASUS TUF Gaming B550plus BIOS3202: 
*Thermaltake TOUGHPOWER GF1 850W 
*ADATA XPG GAMMIX S11PRO; 512GB/sys, 2TB/data 
*G.SKILL F4-3200C16Q-64GFX 
*AMD Ryzen9 5950x + LiquidFreezer II-240 
*XFX Speedster-MERC319-RX6900XT <-AdrenalinEdition 24.12.1
Windows11Pro: 24H2-26100.3915; Direct3D: 9.17.11.0272

Samsung 2xLU28R55 HDR10 (300CD/m², 1499Nits/peak) ->2xDPort
ROCCAT Kave 5.1Headset/Mic ->Analog (AAFOptimusPack 6.0.9403.1)
LG DSP7 Surround 5.1Soundbar ->TOSLINK

DC-GH6/H-FS12060E_HLG4k120p: WB=manual, Shutter=125, ISO=auto/manual
HERO5_ProtuneFlat2.7k60pLinear: WB=4800K, Shutter=auto, ISO=800

VEGASPro22 + XMediaRecode/Handbrake + DVDArchi7 
AcidPro10 + SoundForgePro14.0.065 + SpectraLayersPro7 
K-LitecodecPack17.8.0 (MPC Video Renderer for HDR10-Videoplayback on PC) 

MarkAnthony121 wrote on 2/17/2022, 1:33 AM

I don't know, I'm not familiar with it that's why I asked

Yelandkeil wrote on 2/17/2022, 3:48 AM

In 8bitlegacy project, VEGAS lets all source material "as is" on the timeline, your must adjust them accordingly for a proper editing on your (computer) monitor and set the rendering output to Rec709 signal. 


In 8bitfullrange project, VEGAS attempts to lift source material to the sRGBspace if needed so that you can edit conveniently. And VEGAS renders your edit automatically into the standard Rec709space. 


In 32bitfloating project, you have the chance to profit high level materials e.g. 10bit422footage going to render in Rec2020 space or 10bitdepth format, or even to ST2084 HDR10signal if you want (your Canon R5 CLOG3 10-bit Footage would have a brilliant new appearance). 

But all of them have nothing to do with green/stretched images which could be coursed by incorrect preferences setting or hardware/driver issues. 

Last changed by Yelandkeil on 2/17/2022, 4:05 AM, changed a total of 3 times.

-- Hard&Software for 5.1RealHDR10 --

ASUS TUF Gaming B550plus BIOS3202: 
*Thermaltake TOUGHPOWER GF1 850W 
*ADATA XPG GAMMIX S11PRO; 512GB/sys, 2TB/data 
*G.SKILL F4-3200C16Q-64GFX 
*AMD Ryzen9 5950x + LiquidFreezer II-240 
*XFX Speedster-MERC319-RX6900XT <-AdrenalinEdition 24.12.1
Windows11Pro: 24H2-26100.3915; Direct3D: 9.17.11.0272

Samsung 2xLU28R55 HDR10 (300CD/m², 1499Nits/peak) ->2xDPort
ROCCAT Kave 5.1Headset/Mic ->Analog (AAFOptimusPack 6.0.9403.1)
LG DSP7 Surround 5.1Soundbar ->TOSLINK

DC-GH6/H-FS12060E_HLG4k120p: WB=manual, Shutter=125, ISO=auto/manual
HERO5_ProtuneFlat2.7k60pLinear: WB=4800K, Shutter=auto, ISO=800

VEGASPro22 + XMediaRecode/Handbrake + DVDArchi7 
AcidPro10 + SoundForgePro14.0.065 + SpectraLayersPro7 
K-LitecodecPack17.8.0 (MPC Video Renderer for HDR10-Videoplayback on PC) 

RogerS wrote on 2/17/2022, 5:46 AM

You can try 32 bit video instead which avoids the ACES color management system.

Musicvid wrote on 2/17/2022, 9:47 AM

32 bit Full Range Project, NO Transforms, apply the "CLog3 to REC 709" LUT in the Color Grading Panel. Render to REC 709 Limited, either 8- or 10-bit. Then Level to 709 delivery levels.

As an alternative, my compilation of free camera and grading LUTS, including all of the official Canon LUT Series, can be downloaded here:

https://drive.google.com/open?id=1AKe_ts4pSQ5fJVVGN_vN8Z8GyCUWkhnR&authuser=musicvid%40gmail.com&usp=drive_fs

MarkAnthony121 wrote on 2/17/2022, 1:30 PM

In 8bitlegacy project, VEGAS lets all source material "as is" on the timeline, your must adjust them accordingly for a proper editing on your (computer) monitor and set the rendering output to Rec709 signal. 


In 8bitfullrange project, VEGAS attempts to lift source material to the sRGBspace if needed so that you can edit conveniently. And VEGAS renders your edit automatically into the standard Rec709space. 


In 32bitfloating project, you have the chance to profit high level materials e.g. 10bit422footage going to render in Rec2020 space or 10bitdepth format, or even to ST2084 HDR10signal if you want (your Canon R5 CLOG3 10-bit Footage would have a brilliant new appearance). 

But all of them have nothing to do with green/stretched images which could be coursed by incorrect preferences setting or hardware/driver issues. 

Thank you for trying to help. This is what I get:

8-bit:

 

32-bit (both video and full):

Musicvid wrote on 2/17/2022, 1:37 PM

Can you upload a sample of your actual CLog footage to Drive or Dropbox?

Also, what is your Vegas version and build number? I've haven't seen that exact error before.

MarkAnthony121 wrote on 2/17/2022, 1:44 PM

Can you upload a sample of your actual CLog footage to Drive or Dropbox?

Also, what is your Vegas version and build number? I've haven't seen that exact error before.

Ahh, I fixed it by changing my hardware decoder from my CPU to my GPU. The footage then looks perfect. But sadly it's then clunky and uneditable. I selected Intel QSV for hardware decoding because on my 12900 it makes previewing the footage smooth as butter. Maybe I can get around this by editing my 10bit footage on an 8bit full range timeline then for exporting changing it to 32bit full range and changing my decoder to GPU. Then again, that won't work because it'll throw off the look of the footage slightly I think.

Musicvid wrote on 2/17/2022, 2:25 PM

If you're willing to give the workflow I outlined a try, it will be interesting to see your results.

Or, if you are willing to upload that sample, I'll be happy to give it a try. I am developing a tutorial for log->709, thus my interest.

MarkAnthony121 wrote on 2/17/2022, 2:29 PM

If you're willing to give the workflow I outlined a try, it will be interesting to see your results.

Or, if you are willing to upload that sample, I'll be happy to give it a try. I am developing a tutorial for log->709, thus my interest.

I don't quite understand what you meant. I have such a large workload that I don't do any conversions or anything to save time.

Musicvid wrote on 2/17/2022, 2:36 PM

If you don't wish to convert your CLog for delivery, that's fine. I'll copy you when the tutorial is ready. Welcome to the forums.

RogerS wrote on 2/17/2022, 5:48 PM

So does the footage look green when Intel QSV is enabled for decoding (preferences/ file io)? That is the best decoder in general when it's available.

If it's not working there might be some kind of bug it would be good to get more info on. I haven't seen this error with C-log from the R6.

Do you also have a GPU, and if so what one? That GPU is enabled in preferences/video?

MarkAnthony121 wrote on 2/17/2022, 5:54 PM

That's exactly correct. I use Intel QSV because it's so fast and smooth. I use CLOG3 with the cinema gamut. And yes as I stated above the only way to get the footage to look proper is by switching the decoder to my GPU (3080ti) but then it's virtually impossible to edit unless I make proxies. I don't think it's a GPU issue but more like what you said, a possible bug or some random setting why Intel QSV is not displaying CLOG3 footage properly. And it's the latest build of VP19. Keep in mind this is ONLY occurring when turning on either of the 32bit project properties, either video or full range.

fr0sty wrote on 2/17/2022, 5:57 PM

You can apply a lut or an ACES view transform. To do the view transform, set the project settings to 32 bit (full range). Right click on each media file shot by that CLOG camera, go into its properties, and set the color space to "CLOG" (there may be multiple CLOG options, try them all to see which work best). This should auto-correct the colors to what looks good, then you can fine tune from there. If editing for HDR output, you want to do it this way.

If you want to or must use 8 bit mode, and have no plans for HDR output, use the color grading panel with the input lut set to the CLOG preset.

Last changed by fr0sty on 2/17/2022, 5:58 PM, changed a total of 1 times.

Systems:

Desktop

AMD Ryzen 7 1800x 8 core 16 thread at stock speed

64GB 3000mhz DDR4

Geforce RTX 3090

Windows 10

Laptop:

ASUS Zenbook Pro Duo 32GB (9980HK CPU, RTX 2060 GPU, dual 4K touch screens, main one OLED HDR)

MarkAnthony121 wrote on 2/17/2022, 6:05 PM

You can apply a lut or an ACES view transform. To do the view transform, set the project settings to 32 bit (full range). Right click on each media file shot by that CLOG camera, go into its properties, and set the color space to "CLOG" (there may be multiple CLOG options, try them all to see which work best). This should auto-correct the colors to what looks good, then you can fine tune from there. If editing for HDR output, you want to do it this way.

If you want to or must use 8 bit mode, and have no plans for HDR output, use the color grading panel with the input lut set to the CLOG preset.

I'm not sure how I can make this any clearer for people telling me to change color settings. I have specifically identified that when I have CLOG3 10bit footage on my timeline, and change my project properties to either 32bit video or 32bit full range, the video clips do not display properly. Not wrong color. They literally look like they're not decoded properly. This is solved by changing my file i/o hardware decoder from Intel QSV to my GPU. THEN the clips show up perfectly. The DOWNSIDE to this is that unlike the buttery smoothness of Intel QSV, editing is virtually impossible due to the lag unless I create proxies. So specifically why is Intel QSV decoding unable to display that footage correctly. Because this is not just a color issue lol:

RogerS wrote on 2/17/2022, 6:39 PM

That's exactly correct. I use Intel QSV because it's so fast and smooth. I use CLOG3 with the cinema gamut. And yes as I stated above the only way to get the footage to look proper is by switching the decoder to my GPU (3080ti) but then it's virtually impossible to edit unless I make proxies. I don't think it's a GPU issue but more like what you said, a possible bug or some random setting why Intel QSV is not displaying CLOG3 footage properly. And it's the latest build of VP19. Keep in mind this is ONLY occurring when turning on either of the 32bit project properties, either video or full range.

It shouldn't decode like this. Can you provide MediaInfo for exactly what is in this file? https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-vegas-pro-file-properties--104561/

Could you also make a few second sample with the same settings available for download (Dropbox, Google Drive, etc.) so other Intel users can validate?

Assuming we can replicate, I'd encourage you to file a support request (go back up to the top here and click on support but not then to ask the community) so Magix can address it.

MarkAnthony121 wrote on 2/17/2022, 7:06 PM

It shouldn't decode like this. Can you provide MediaInfo for exactly what is in this file? https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-vegas-pro-file-properties--104561/

Could you also make a few second sample with the same settings available for download (Dropbox, Google Drive, etc.) so other Intel users can validate?

Assuming we can replicate, I'd encourage you to file a support request (go back up to the top here and click on support but not then to ask the community) so Magix can address it.

LINK TO THE FOOTAGE COMPARISONS:

https://drive.google.com/drive/folders/102QLXH7SQKgjfY0nCA0NT1GdHC3YqnYT?usp=sharing

File info:

Complete name                            : C:\Users\Mark\Desktop\CLOG3 Test\702A3892.MP4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (mp42/hvc1/CAEP)
File size                                : 91.1 MiB
Duration                                 : 4 s 338 ms
Overall bit rate                         : 176 Mb/s
Encoded date                             : UTC 2022-02-16 09:14:24
Tagged date                              : UTC 2022-02-16 09:14:24

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Format Range@L5.1@High
Codec ID                                 : hvc1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 4 s 338 ms
Bit rate                                 : 175 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.882
Stream size                              : 90.7 MiB (100%)
Language                                 : English
Encoded date                             : UTC 2022-02-16 09:14:24
Tagged date                              : UTC 2022-02-16 09:14:24
Color range                              : Full
matrix_coefficients_Original             : BT.709
Codec configuration box                  : hvcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 4 s 331 ms
Bit rate mode                            : Constant
Bit rate                                 : 256 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 134 KiB (0%)
Language                                 : English
Encoded date                             : UTC 2022-02-16 09:14:24
Tagged date                              : UTC 2022-02-16 09:14:24

Other
ID                                       : 3
Type                                     : Time code
Format                                   : QuickTime TC
Duration                                 : 4 s 338 ms
Bit rate mode                            : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Time code of first frame                 : 07:08:00:04
Time code, striped                       : Yes
Language                                 : English
Encoded date                             : UTC 2022-02-16 09:14:24
Tagged date                              : UTC 2022-02-16 09:14:24

RogerS wrote on 2/17/2022, 8:11 PM

Thanks Mark, very helpful. So it's 10-bit HEVC 4:2:2. That won't decode with most GPUs (nothing from NVIDIA or AMD can decode it AFAIK) so in those cases it just defaults back to a software decoder and performance suffers.

On my 7th generation Intel, it also doesn't decode with the iGPU and as a result looks fine but plays back terribly. Here it is in 32-bit ACES with the Canon C-Log 3 transform:

@VEGASHeman Could you please take a look at this issue of Canon 10-bit 4:2:2 HEVC decoding being green and distorted with 12th generation Intel while in 32-bit ACES mode? Original files and the failed test are in the post above this one.

MarkAnthony121 wrote on 2/17/2022, 8:17 PM

Thanks! I'll cross my fingers that someone is able to identify any solutions or reasons for this. I can still edit in 8-bit perfectly, I'm just not maxing out its full potential.

RogerS wrote on 2/17/2022, 8:55 PM

Hi Mark, until it's fixed on the Vegas or Intel driver side, I'd go the proxy route with one of the 32-bit modes if you run into banding with 8-bit full. 32-bit video and the built-in C-log LUT in the color grading panel looked pretty good when I tried it.

I shot that Canonet for years by the way.

Musicvid wrote on 2/17/2022, 10:02 PM

The files open exactly the same in any combination of 8 or 32 bit projects, hardware (QSV) or software decoders.

This render uses QSV hardware decoder, 32 bit fullrange project, no transform, and the right half with Canon LUT CinemaGamut_CanonLog3-to-BT709_BT709_33_FN_Ver.1.1 Levels, Gamma, and some Grading was applied.

MarkAnthony121 wrote on 2/17/2022, 10:05 PM

The files open exactly the same in any combination of 8 or 10 bit projects, hardware (QSV) or software decoders.

This render uses QSV hardware decoder, 10 bit fullrange project, no transform, and the right half with Canon LUT CinemaGamut_CanonLog3-to-BT709_BT709_33_FN_Ver.1.1 Levels, Gamma, and some Grading was applied.

Do you mean 8 and 32 bit pixel format projects?

MarkAnthony121 wrote on 2/17/2022, 10:06 PM

Hi Mark, until it's fixed on the Vegas or Intel driver side, I'd go the proxy route with one of the 32-bit modes if you run into banding with 8-bit full. 32-bit video and the built-in C-log LUT in the color grading panel looked pretty good when I tried it.

I shot that Canonet for years by the way.

Yea I'll figure it out one way or another. And yes that Cononet is fun, just started shooting with it lol

Musicvid wrote on 2/17/2022, 10:19 PM

Do you mean 8 and 32 bit pixel format projects?

Yes sorry, changed.

The files open exactly the same in any combination of 8 or 32 bit projects, hardware (QSV) or software decoders.

This render uses QSV hardware decoder, 32 bit fullrange project, no transform, and the right half with Canon LUT CinemaGamut_CanonLog3-to-BT709_BT709_33_FN_Ver.1.1 Levels, Gamma, and some Grading was applied.