Vegas 21:

https://drive.google.com/file/d/1jM7Sa82imwubq7L4YQNktZt8QoUbP1Si/view?usp=sharing

Vegas 22:

https://drive.google.com/file/d/1h0hESoDd3h_pI2hn_6NFlHqCMdGGpsqj/view?usp=sharing

Without access rights, nobody will be able to download that to support you.

And which one is the original footage? Would be great to have that too, to support you.

And as said - we need the footage specification too.

I've adjusted the access rights. Hopefully these links will work now. They are both rendered output from Vegas. Vegas 21 renders with a blocky sky, and Vegas 22 renders with a blocky sky and adds brightly coloured pixels.

I have attached a sample source clip from the iPhone 13. When I play this back in Media Player it plays as HDR but also shows the blocky skies problem.

https://drive.google.com/file/d/1ISs3vMk4yT4dnX4M2OzXLk6E-Yo0qcWC/view?usp=sharing

General
Complete name                            : G:\2024 Brighton\iPhone\CP_00290.MOV
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   0000.00 (qt  )
File size                                : 53.2 MiB
Duration                                 : 14 s 931 ms
Overall bit rate                         : 29.9 Mb/s
Frame rate                               : 50.000 FPS
Encoded date                             : 2024-08-04 18:20:28 UTC
Tagged date                              : 2024-08-04 18:20:43 UTC
Writing library                          : Apple QuickTime
dateRecorded                             : 2024:08:04
cinema.p3.exposureMode                   : Center
cinema.p3.focusMode                      : AFC
cinema.p3.iso                            : 49
cinema.p3.shutterSpeed                   : 1/2667
cinema.p3.shutterAngle                   : 7º
cinema.p3.whiteBalanceMode               : WB Lock
WhiteBalanceKelvin                       : 5195
WhiteBalanceTintCc                       : 5
cinema.p3.toneMapping                    : Local
cinema.p3.cameraName                     : Back Camera
cinema.p3.stabilizationMode              : Standard
com.apple.quicktime.title                : Alton Towers
com.apple.quicktime.director             : Andrew Stevenson
com.apple.quicktime.location.ISO6709     : +50.818-000.1344-001.8705/
com.apple.quicktime.location.accuracy.ho : 927.575688
com.apple.quicktime.location.accuracy.ve : 29.691875
com.apple.quicktime.software             : Cinema P3 Pro Camera
com.apple.quicktime.creationdate         : 2024-08-04T18:20:28Z

Video
ID                                       : 2
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L5.1@Main
HDR format                               : Dolby Vision, Version 1.0, dvhe.08.08, BL+RPU, HLG compatible
Codec ID                                 : hvc1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 14 s 931 ms
Source duration                          : 14 s 999 ms
Bit rate                                 : 29.7 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Frame rate                               : 50.000 FPS
Minimum frame rate                       : 49.950 FPS
Maximum frame rate                       : 50.050 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.072
Stream size                              : 52.8 MiB (99%)
Source stream size                       : 53.0 MiB (99%)
Title                                    : Core Media Video
Encoded date                             : 2024-08-04 18:20:28 UTC
Tagged date                              : 2024-08-04 18:20:43 UTC
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : HLG
Matrix coefficients                      : BT.2020 non-constant
Codec configuration box                  : hvcC+dvvC

Audio
ID                                       : 1
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 14 s 911 ms
Source duration                          : 15 s 40 ms
Bit rate mode                            : Constant
Bit rate                                 : 128 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                              : 230 KiB (0%)
Source stream size                       : 232 KiB (0%)
Title                                    : Core Media Audio
Encoded date                             : 2024-08-04 18:20:28 UTC
Tagged date                              : 2024-08-04 18:20:43 UTC

@Andrew-Stevenson

I have checked your 3 files. What I see here is, that the blocking is available in the original footage too. So if that is the case, why should it not be available in the rendered footage too? So that is nothing to blame Vegas, but to blame the iphone - to my opinion. If you would not see that in the original footage too, then it would be different - but so?

The reasons for the blocking could be in the low datarate used by the iphone - and the compression algorithmen used by the iphone. One way to improve that should be to shoot with an improved codec. You should understand, that a lot of people shoot in RAW or ProRes to avoid such issues. HEVC is compressed strongly.

The second shortcome is to shoot in HLG. HLG was desigened as presentation format, and was not designed to be transformed dramatically - as it happens here is that you transform HLG to PQ. Not the best idea.

The reason why HLG should not be transformed dratically is the gamma curve applied in HLG. In the upper stops you do not have a hugh number of data available. For that reason people shoot in log typically. If you shoot in HLG, you should stay in HLG at least (but this will not overcome the blocking, since that is available in the original HLG footage).

In addition - the iphone seems to sharpen the original footage in a strong way. Not so great. Typically that happens in the post production, and should be avoided in the aquisition format.

So overall, we have issues with HDR in Vegas. But here we have issues in the original aquisiton footage, and if you wish to improve your results, you think about to start in the aquisition of the footage.

@Andrew-Stevenson

I have checked your 3 files. What I see here is, that the blocking is available in the original footage too. So if that is the case, why should it not be available in the rendered footage too? So that is nothing to blame Vegas, but to blame the iphone - to my opinion. If you would not see that in the original footage too, then it would be different - but so?

The reasons for the blocking could be in the low datarate used by the iphone - and the compression algorithmen used by the iphone. One way to improve that should be to shoot with an improved codec. You should understand, that a lot of people shoot in RAW or ProRes to avoid such issues. HEVC is compressed strongly.

The second shortcome is to shoot in HLG. HLG was desigened as presentation format, and was not designed to be transformed dramatically - as it happens here is that you transform HLG to PQ. Not the best idea.

The reason why HLG should not be transformed dratically is the gamma curve applied in HLG. In the upper stops you do not have a hugh number of data available. For that reason people shoot in log typically. If you shoot in HLG, you should stay in HLG at least (but this will not overcome the blocking, since that is available in the original HLG footage).

In addition - the iphone seems to sharpen the original footage in a strong way. Not so great. Typically that happens in the post production, and should be avoided in the aquisition format.

So overall, we have issues with HDR in Vegas. But here we have issues in the original aquisiton footage, and if you wish to improve your results, you think about to start in the aquisition of the footage.

 

It looks like 50fps HDR is too much for the iPhone 13, I haven't seen any blocking at 24fps (yet!). Unfortunately RAW and ProRes are not available for it on the standard phone. I was aware of the sharpening the iPhone does, sometimes it looks a bit like it's been run through a filter that makes it look a bit computer generated. For that reason, I only use iPhone 13 when using the other "proper" camera is not practical.

Regarding the second issue, did you see any difference between the clips rendered in Vegas 21 and 22? The Vegas 22 rendered clip had an entirely new issue that there were thousands of very bright randomly colour pixels all over the image. Not present in the Vegas 21 clip, nor in the source clip. I would post a still of the differences but haven't yet found a way to capture an HDR screen in Windows.

@Andrew-Stevenson, for your comparison. Tell me if you can't download. Will delete in 3 days.

https://drive.google.com/drive/folders/1P1fvTHeFsfe8cLR544Sg43Gq3piO-4ik

There were two clips, not sure which one you are referring to. Was the gh5* rendered on Vegas 21 or 22? It had the blocky sky which I think has been resolved as the iPhone. What is interesting is that it didn't have the brightly coloured random pixels issue which arrived in my Vegas 22 render.

The P1020437 clip wouldn't play.

Regarding the second issue, did you see any difference between the clips rendered in Vegas 21 and 22? The Vegas 22 rendered clip had an entirely new issue that there were thousands of very bright randomly colour pixels all over the image. Not present in the Vegas 21 clip, nor in the source clip. 
 

I have checked your footage in my 32 inch HDR editing monitor, and have not seen that. I can check that again.

Please tell me, how you have seen that? From the timeline in Vegas? From an media player? On a HDR monitor, or HDR TV?

Regarding the second issue, did you see any difference between the clips rendered in Vegas 21 and 22? The Vegas 22 rendered clip had an entirely new issue that there were thousands of very bright randomly colour pixels all over the image. Not present in the Vegas 21 clip, nor in the source clip. I would post a still of the differences but haven't yet found a way to capture an HDR screen in Windows.

Yes, this issue is here visible too.

However, but not with my own v-log footage. I do not see here colored pixels - I have used the ACEScc transformation, and tested it with and without the CGP.

So it would be helpful to know, which effects you had applied to your footage, and which render template you have used exactly.

Regarding the second issue, did you see any difference between the clips rendered in Vegas 21 and 22? The Vegas 22 rendered clip had an entirely new issue that there were thousands of very bright randomly colour pixels all over the image. Not present in the Vegas 21 clip, nor in the source clip. I would post a still of the differences but haven't yet found a way to capture an HDR screen in Windows.

Yes, this issue is here visible too.

However, but not with my own v-log footage. I do not see here colored pixels - I have used the ACEScc transformation, and tested it with and without the CGP.

So it would be helpful to know, which effects you had applied to your footage, and which render template you have used exactly.

First, it's important to note that the project rendered without the brightly coloured random pixels in Vegas 21. I opened the project in Vegas 22 and just rendered with the same template and no other changes and it came out very differently. So obviously there is a difference between V21 and V22 with everything else being equal.

Having said that this issue only occurs on iPhone 13 footage. The footage I shot on a Panasonic HC-X2 in VLog renders exactly the same on Vegas 21 and Vegas 22.

I am coming to the conclusion that HDR on iPhone is just best avoided!

The project settings are as follows:

HDR Mode: HDR10

Pixel format: 32-bit floating point (full range)

Compositing gamma: 1.000 (Llinear)

ACES version: 1.2

ACES color space: Default (ACES2065-1)

View transform: Rec.2020 ST2084 1000 nits (ACES)

The clip's media settings are as follows:

Color space: Rec.2020 HLG (1000 nits)

Color range: Undefined

The render template is:

HDR10 UHD 2160p 50fps

I have seen the pixel static issue in multiple versions of VEGAS. It has been reported.

I am coming to the conclusion that HDR on iPhone is just best avoided!

Maybe more because of the blocking and HLG as aquisition format.

ACES color space: Default (ACES2065-1)

This mode is still a questionmark at the moment.

I have seen the pixel static issue in multiple versions of VEGAS. It has been reported.

Having said that this issue only occurs on iPhone 13 footage. The footage I shot on a Panasonic HC-X2 in VLog renders exactly the same on Vegas 21 and Vegas 22.

I have never been able to repro coloured pixels with my EVA1 vlog footage either. Fr0sty has seen that with his footage and his systems.

Not sure what causes that. But while the blocking seems to be an issue by the iphone/maybe HLG, such pixel seems to be a Vegas issue.

@Andrew-Stevenson

Thank you so much (!) for providing an example of your source and the MediaInfo readout. Doing so has put your inquiry in a whole new light, one that may lead you to a resolution, by suggesting more appropriate shooting and render formats.

• Your source footage is DolbyVision(r) HLG. This presents a couple of problems for Vegas Pro, one being a licensure / compatibility issue, the other being the need to choose a render format more suited to your HLG source.
• Vegas does not support DolbyVision due to licensing restrictions. The Dynamic Metadata track, therefore, cannot be imported, and one is faced with constantly changing color information that is unmitigated in the software. The parent company has hinted that this is probably not going to be resolved any time soon. At this time, I know of no free video converters that decode DolbyVision to conventional formats.
• 
• The HLG colorspace of your source footage does not contain but a small percentage of the dynamic range, consisting of luminance and chroma, to fill the ST2084 HDR10 colorspace you intended.
• Let's say your HLG source fills a 5 gallon bucket with actual data. You can certainly pour that data into a 20 gallon HDR10 bucket, where it will all sit in the bottom. And you can pour only 5 gallons of data back out.
• 
• A rather persistent internet myth among gamers and hobbyists has it that by simply encoding ordinary video source in HDR colorspace, it somehow transforms the bit data to fill that space, as if by Alchemy or some quantum suspension of Newton's Laws of Physics. Of course this does not happen.
• However, in deference to all the Wishful Thinkers of at least two generations, recent advances in AI Transformation now available to the public have demonstrated the practicality of Bit Depth Upfilling, by which the gaps in the color and luminance spectrum in the Frequency Domain can now be "filled in" with guesstimates, and my own guess is that with the focus of hardware improvements over the coming years, "may" become practical for consumer video encoding, perhaps in your lifetime (certainly not mine)!
• 

Thank you again for providing the relevant video source information along with your intended goals. It makes assessing and addressing your situation so much easier on all of your forum peers, and I am confident that with this and subsequent input to your question, including corrections to my response as needed, you will be able to put this discussion to rest and mark one of these responses as The Solution.

Welcome to the discussions. You have an inquiring mind, and a fairly obvious interest in learning, and you will find over time that those are really all it takes. 😌

Instead of talking about myth and alchemy, it would be smart to stick to the facts. Dolby Vision HDR requires a special license, if someone wants to ENCODE footage in Dolby Vision HDR. But that is not the case here. The footage is HLG compatible, and is DECODED in Vegas quite will. So that is no issue here at all, and for sure no problem for Vegas.#

The encoding step to that format happens in the iphone, and you can ask Apple if they hold a license to do that.

For sure Vegas cannot render to Dolby Vision HDR - even Resolve can do that only with special hardware/licenses. But what can be done is to encode the footage either to HLG, and work with HLG project settings, or to encode the footage to HDR10. Both is possible.

For sure that is no solution what is said here, but simply wrong.

And here the link to the license owner of Dolby Vision HDR.

And here how this footage is decoded in Vegas. Simply as HLG.

Project settings for HLG in Vegas:

Encoder settings for HLG in Vegas - here with the example of the HEVC encoder:

I have seen the pixel static issue in multiple versions of VEGAS. It has been reported.

Thanks for confirming that is a known issue fr0sty. Brief but always insightful comments, much appreciated!

And here how this footage is decoded in Vegas. Simply as HLG.

Project settings for HLG in Vegas:

Encoder settings for HLG in Vegas - here with the example of the HEVC encoder:

According to the metadata the iPhone clip is HLG/HDR, but if I drag it to Vegas and allow it to set the project settings optimally it chooses:

Media Properties:

Color space: Rec.2020 HLG (1000 nits)

Color range: Limited

Project Properties:

HDR Mode: Off

Given the ubiquity of iPhones and their ability to shoot HDR (admittedly low-grade 5 gallon as mark-y puts it), it would be useful if Magix could document the correct settings to use for Vegas or choose the correct defaults.

Can anyone suggest the correct project and media settings for this clip?

@Andrew-Stevenson

Thank you so much (!) for providing an example of your source and the MediaInfo readout. Doing so has put your inquiry in a whole new light, one that may lead you to a resolution, by suggesting more appropriate shooting and render formats.

• Your source footage is DolbyVision(r) HLG. This presents a couple of problems for Vegas Pro, one being a licensure / compatibility issue, the other being the need to choose a render format more suited to your HLG source.
• Vegas does not support DolbyVision due to licensing restrictions. The Dynamic Metadata track, therefore, cannot be imported, and one is faced with constantly changing color information that is unmitigated in the software. The parent company has hinted that this is probably not going to be resolved any time soon. At this time, I know of no free video converters that decode DolbyVision to conventional formats.
• 
• The HLG colorspace of your source footage does not contain but a small percentage of the dynamic range, consisting of luminance and chroma, to fill the ST2084 HDR10 colorspace you intended.
• Let's say your HLG source fills a 5 gallon bucket with actual data. You can certainly pour that data into a 20 gallon HDR10 bucket, where it will all sit in the bottom. And you can pour only 5 gallons of data back out.
• 
• A rather persistent internet myth among gamers and hobbyists has it that by simply encoding ordinary video source in HDR colorspace, it somehow transforms the bit data to fill that space, as if by Alchemy or some quantum suspension of Newton's Laws of Physics. Of course this does not happen.
• However, in deference to all the Wishful Thinkers of at least two generations, recent advances in AI Transformation now available to the public have demonstrated the practicality of Bit Depth Upfilling, by which the gaps in the color and luminance spectrum in the Frequency Domain can now be "filled in" with guesstimates, and my own guess is that with the focus of hardware improvements over the coming years, "may" become practical for consumer video encoding, perhaps in your lifetime (certainly not mine)!
• 

Thank you again for providing the relevant video source information along with your intended goals. It makes assessing and addressing your situation so much easier on all of your forum peers, and I am confident that with this and subsequent input to your question, including corrections to my response as needed, you will be able to put this discussion to rest and mark one of these responses as The Solution.

Welcome to the discussions. You have an inquiring mind, and a fairly obvious interest in learning, and you will find over time that those are really all it takes. 😌

@mark-y That's two attempts now to shut down this thread in which others are providing useful assistance to me. Please take your condescension elsewhere.

It does not fill me with confidence that one part of the program says the footage is HLG/HDR and the other says not.

Your HLG footage is identified automatically - and that in a correct way. See the first picture above.

What are the correct project and media settings for this clip?

Media settings - as shown above in the first picture. Happens autmatically.

Project settings - here you can use both HDR PQ and HLG settings. This is defined by the user - what is logical, since the user has to decide if he wishes to tranform the footage to HDR PQ or to HLG.

So there is nothing wrong.

https://www.vegascreativesoftware.info/us/forum/vegas-pro-18-update-4-build-482-general-discussion--127860/?page=6#ca798836

@Andrew-Stevenson

What are the correct project and media settings for this clip?

Thanks for keeping an open mind.

Since this thread has taken a turn with the posting of your file information, I'll address that question in a separate thread, perhaps as early as this evening. I actually had quite a wrestling match with Dolbyvision when it first came out, and learned a lot from that experience.

As far as HLG alone, decoding this hybrid acquisition format and exporting to an appropriately fitting output format is relatively straightforward. I'll address that as well, and post my own rendered interpretation in that same thread.

Your relatively constant lighting has allowed you to mostly skate past the issue of the missing Dolby Dynamic Metadata chunk, and I'll provide my own interpretation at that time. I won't, for instance, address the dynamic color shift from blue to yellow that begins at 0:08 seconds and remains.

Until then . . .

It does not fill me with confidence that one part of the program says the footage is HLG/HDR and the other says not.

Your HLG footage is identified automatically - and that in a correct way. See the first picture above.

What are the correct project and media settings for this clip?

Media settings - as shown above in the first picture. Happens autmatically.

Project settings - here you can use both HDR PQ and HLG settings. This is defined by the user - what is logical, since the user has to decide if he wishes to tranform the footage to HDR PQ or to HLG.

So there is nothing wrong.

That makes sense to me, thanks for the explanation. To summarise where things have got to then:

1. Blocky skies - iPhone/CinemaP3 App HDR problem.

2. Sparkly random pixels on HDR render - Vegas problem.

3. HDR button goes out of sync - Vegas problem.

4. HDR preview distorted aspect ratio - Vegas problem.

5. HDR scopes stop working - Vegas problem.

6. HDR preview stops working - Vegas problem.

I will do some test shootings to see if I can find the optimal settings for HDR on iPhone when using the CinemaP3. The sweet spot where the HDR works and the sky is not blocky. I don't think it is as simple as a data rate issue, since I find it curious that the areas with all the motion (the sea) are clear, but skies which are largely static are not. Yes, in the example clip presented the camera was panning so there is a lot of movement across the entire image, but I have many other clips from the phone where the whole image is largely static but the sky is still blocky as hell. I suspect an app/codec issue on the Phone or CinemaP3 app in relation to issue 1.

Mark-y misses again the point. That it is unlikely (and unnecessary) to establish a license agreement for Dolby Digital HDR is a complete different story. What Derek states here, has NO connection to this discussion here.

Who beliefs that such a license would be necessary to decode HLG in Vegas, does simply not know what he is talking about.

https://www.vegascreativesoftware.info/us/forum/vegas-pro-18-update-4-build-482-general-discussion--127860/?page=6#ca798836

@Andrew-Stevenson

What are the correct project and media settings for this clip?

Thanks for keeping an open mind.

Since this thread has taken a turn with the posting of your file information, I'll address that question in a separate thread, perhaps as early as this evening. I actually had quite a wrestling match with Dolbyvision when it first came out, and learned a lot from that experience.

As far as HLG alone, decoding this hybrid acquisition format and exporting to an appropriately fitting output format is relatively straightforward. I'll address that as well, and post my own rendered interpretation in that same thread.

Your relatively constant lighting has allowed you to mostly skate past the issue of the missing Dolby Dynamic Metadata chunk, and I'll provide my own interpretation at that time. I won't, for instance, address the dynamic color shift from blue to yellow that begins at 0:08 seconds and remains.

Until then . . .

 

I'll look forward to your thread!

I need to do some more experimentation with the CinemaP3 app on the iPhone to see what codec is uses under various conditions. I have some footage that is DolbyVision and others that are not. I have found that it is easy to disturb the settings the app uses so some of the footage I captured was in 50fps and some in 24fps or 30fps and there are differences in the MediaInfo of the clips. I will be trying to identify what is the discerning part of the settings that makes the difference between a blocky or non-blocky sky.