Loss of highlight detail part 2
Loss of highlight detail, this time during rendering. My preferred intermediate codec is ProRes and this loss of detail only happens when rendering from Cin, it's OK from other NLEs. It is nothing to do with the latest Cin update, which I waited for before reporting this. It is not just ProRes, it is easier to say the only output options to give full detail are mkv, specifically HuffYUV, rather than list those that don't. I have tested all options that offer a visually lossless output.
I have tried all variations of ProRes and ProRes_ks, I have also purged the .bcast 5 folder and started again from scratch. I also tried from Kubuntu to eliminate it being a Manjaro thing.
Although the results of my ProRes rendering are not 100% the same as the original. I have a video showing no discernible difference, but I have to explain what you see in the video.
#1 ffplay of the very short original video that is 1920x1080.
#2 ffplay of the Cinelerra rendered using ProRes, profile 5.
#3 I run ydiff (explained in the manual) which is a subtraction of the 3 rgb channels between the 2 video files.
(a) you will see a grey colored screen with me wiggling the cursor around and note how you see no lines showing real differences/loss. If there was a lot of detail losses, you would see them as little lines. The manual in section C.1 provides a little more information.
(b) next you see the numerical value differences in columns 2, 3, and 4. If the files are exact, then these will all be 0. You can see that they are not. I believe column 5 is the frame number.
We could provide a ydiff compiled program for you to test on your video for Arch (probably that would run on Manjaro too) if you would like to try this. However, it may be necessary to have some specific library installed and I do not know what that might be.
Thanks Phyllis. I wasn't sure how to connect the two, because the effect is the same, while at the same time differentiate between them because the cause is different. Yes, part 1 was and still is, solved.
I did try visually_lossless. m2ts. However, since posting I fiddled a bit more and found that DNxHD, which won't work because it doesn't handle UHD, leads into DNxHR which does (a mite confusing, but Shotcut does the same thing). Rendering as DNxHR HQX also keeps highlight detail. Hopefully that information may help.
While DNxHR is an improvement on HuffYUV (smaller file sizes and motion does not halt as it sometimes does with Huffy) and I can work with it, it is less useful to me than ProRes.
I don't use any ffmpeg commands, GUI only.
Thanks for the demo, but it doesn't really address my problem, the way to see what I am trying to explain is to look at the previous thread and compare the YUVA 8-bit png's with the RGBA-FLOAT ones, because what is happening is almost identical, the only difference is that now the detail is present in the compositor window and missing in the rendered version.
OK, I will test using the additional information you provided. Hopefully, we can get this resolved.
We would like to include a potential fix in the July 31 new builds but unfortunately we have been struggling with this over a few days now and are no closer to finding a test case that shows the problem.
Could you send us a short video (like of the sky with clouds and trees and a building, like the grey skies png you sent previously) that was created on the same camera:
Camera details: Fuji X-T3 shooting in F-Log at 1 stop over exposed (1 to 2 stops recommended), 10-bit interframe HEVC at 200mbps.
that definitely will show us when we render it to Prores, the loss of detail. Thank you. You can send here or privately to: [email protected]
Personally I often use pCloud which allows to share through the cloud up to 10G with a free account and it offers an automated synchronization application for linux.
I know that there are even other cloud sharing services with even greater transfer capabilities through free accounts.
Thunderbird offered me Filelink, which I declined. Having just spent a couple of days trying to find a format that would do what is required, I wasn't going to spend (even more) time on setting it up just for one file, but I'll know how to send big files in future if I ever have the same need again.
Unfortunately, we still can not see any problem after 2 more days of testing and even using the Highlights...mov file you provided. All we see is that there is no loss of detail and no banding. The attached 2 png-s show (the 2nd png is in the next note):
1) inside of Cinelerra we did a "subtract" in the patchbay of the original file and the rendered prores file and the difference is shown on the first track in the Compositor. It is all grey with no obvious banding or pixel differences.
2) blowing up the last frame of each of the before and after videos and looking at the detailed pixels, they really look the same. GG also rewrote the ydiff program to handle more than 8 bits and when we compare the 2 files, there is no perceivable differences.
It looks like you will have to continue to use a workaround until something changes so that we can detect the difference.
which means I didn't manage to send you a good original to work from after all
Resending screen capture because what you saw in blow_up.png on the right side in the cloud formation does look wrong for the pro render portion BUT I used "xv" to blow it up and it looks like that software changed it. First screen capture I am sending now is from a simple "print screen" from the keyboard of the last frame when I did an ffplay on the file you sent: Highlights test BT709 DNxHR.mov .
The next note will be a "print screen" on the file after rendered using Pro in Cinelerra
I ask again, is that how it arrived in your inbox?
Yes, that is how it arrived. I downloaded it again just now to make sure. But that is very interesting information. The screencapture png I sent of the Highlights...mov file was from an "ffplay" command (that is part of ffmpeg). But now when I load into Cinelerra it looks like there is more detail in the cloud formation to the left of the building than what ffplay shows. Will let GG know exactly where to look and will try not to bother you anymore -- but like you say it is for the good of Cin !! Thanks.
I guess this must be part 3!
I read the release notes then updated Cin to 0831 and did some test renders, I also did a test render from 0731 for a comparison. When I opened the render window for ProRes Pro, the default showed as profile 2, but that is maybe how I had it set last time I tried it. ProRes Pro profile 2 and 3, also ProRes_ks Pro profile 3 and the default 4444 all rendered with loss of highlight detail. DNxHR_HQ rendered all the detail as expected. Just to make sure the yellowing that appears in the ProRes Pro output isn't masking the detail I removed as much yellow as I could, but it made no difference to the visible detail. There is no discernible difference between the 0731 and 0831 renders.
Unfortunately, this is what we suspected the results would be since we made no coding changes. The Prores option changes were just for better results for users who just take defaults.
Until we can come up with something else to try, the workarounds you have found are all there is.