28.08.2022, 01:32
Hi Selur,
I tried the dev release (2022.08.27.1) you sent me but, unfortunately, the same exact failure still occurs with the example file I sent you. Maybe your changes didn't commit properly to the build?
I really must be blind. I can't find where I can choose the bit depth. I checked under the ProRes tab (which always shows the source bit depth) and the various filter tabs... Should I be checking a different tab?
It wouldn't simply discard the last two bits of precision, a la audio bit crushing?
Yes, QTGMC works with 10-bit, but a bug causes washed out output when source matching is enabled. We discussed this back in July. I still have to file a bug report at the HAvsFunc GIT. It used to work with an old dev build I used in April so I'm sure it's something they did...
Yes, I'm messing around with these parameters to see if the old FCC color gamut (which is wider than SMPTE 601 but smaller then Rec 2020) can be reproduced with these parameters. I plan on researching how these tags are prioritized/interpreted in the future. Setting these on files that are known good (most of my FFV1 captures) has been OK on playback in the applications I use so far.
My BlackMagic hardware is capturing as full but flagging as limited via the Thunderbolt interface so I've been updating the tags to full range. Its a big bug on their end and I'm still figuring out the best way to compensate on my end. For now, I'm flagging the master files as full range and converting to limited range with the "levels" filter only when making output for YouTube, etc. The tags work so far in my known good files...
I tried the dev release (2022.08.27.1) you sent me but, unfortunately, the same exact failure still occurs with the example file I sent you. Maybe your changes didn't commit properly to the build?
Quote:Open file, set ProRes with 8bit as output.
I really must be blind. I can't find where I can choose the bit depth. I checked under the ProRes tab (which always shows the source bit depth) and the various filter tabs... Should I be checking a different tab?
Quote:If you would feed 10bit content to a 8bit encoder it would simply crash, since it could not handle the extended color ranges. (and even if it would clip the ranges to 0-255 or 16-235 you would not get washed out colors but basically a black output)
It wouldn't simply discard the last two bits of precision, a la audio bit crushing?
Quote:That is not a problem with 10bit or 8bit handling, normally I would say it sounds like a color matrix or luma range issue...
...QTGMC works fine here with 10bit content,... (support for 10bit was added a year ago ar so to QTGMC...)
Yes, QTGMC works with 10-bit, but a bug causes washed out output when source matching is enabled. We discussed this back in July. I still have to file a bug report at the HAvsFunc GIT. It used to work with an old dev build I used in April so I'm sure it's something they did...
Quote:Also something is seariously wrong with the flagging of your input.
Yes, I'm messing around with these parameters to see if the old FCC color gamut (which is wider than SMPTE 601 but smaller then Rec 2020) can be reproduced with these parameters. I plan on researching how these tags are prioritized/interpreted in the future. Setting these on files that are known good (most of my FFV1 captures) has been OK on playback in the applications I use so far.
Quote:Also HDR content usually does not use 'full' but 'limited' color range.
My BlackMagic hardware is capturing as full but flagging as limited via the Thunderbolt interface so I've been updating the tags to full range. Its a big bug on their end and I'm still figuring out the best way to compensate on my end. For now, I'm flagging the master files as full range and converting to limited range with the "levels" filter only when making output for YouTube, etc. The tags work so far in my known good files...