which means I didnt 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
Thanks Phyllis, both those show the problem, although slightly differently in each case. If you look at the PNGs I sent for the original report and compare the YUVA to the RGBA you will see that there is detail in the YUVA that is not there in the RGBA. The problem is that big burnt-out blob in the cloud formation to the left of the building which should have some detail in it, the same in the top RH corner of the other clip.
I ask again, is that how it arrived in your inbox? I ask because several times I thought I had managed to output a clip you could test with, but after attaching to a post each one had the burnout, so was useless and I deleted the post.
There seems to be two options left, first to use Filelink and send the complete raw (as opposed to RAW) clips and second to try posting on Dailymotion for you to download, assuming it doesnt distort there. Otherwise I am at a loss as to what to do.
Im quite happy to output undistorted in DNxHR, but the ProRes and other formats needs fixing for the good of Cin.
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 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 isnt 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.
May I ask quite what you mean by for users who just take defaults? Default what exactly?
What I meant by defaults was the user does a Render; the Render menu has the default File Format of FFMPEG and then they choose the File Type of Pro but it is not obvious to click on the Video wrench to change the Video Preset for prores.pro from profile=2 quality to the more desirable end product of profile=3. The wrench is just weird to an occasional user.
I still would like to get a resolution sometime on the loss of detail because this is not the first time it has been noted and I am quite sure it will come up again!
** Posted by: @phyllissmith **I still would like to get a resolution sometime on the loss of detail because this is not the first time it has been noted and I am quite sure it will come up again!
Well, if there is any way I can help, please say and I will do my best.
Short answer is no. It is going to take a real pro to correctly analyze and get a solution for this loss of detail problem. They would have to be able to convey to a programmer/coder how to then fix the problem. The original author was highly competent in video/color editing as well as a programmer and we always hold out hope that someday he might be interested in helping.
Just wondering if you get the same problem by rendering with h265-12bit using the 8/10/12 bit appimage at: