I agree about clutter and confusing new users with too many presets. DNxHD is a perfect example. I never use that format, so all the variants are clutter to me. Granted, I understand their convenience when submitting video to TV stations where the settings have to be absolutely right, so I wouldn’t lobby to remove them. But to the point, lots of people will never use Ut Video, so there’s no reason it should clutter their list either.
Fortunately, Shotcut already has YUV422 and RGB versions of the Ut Video preset. When I made that comment about a second preset for RGB, I forgot that Dan created a Ut Video preset under the “alpha” section too, which by nature is already in RGBA. I think RGBA would be sufficient for non-alpha RGB users too. The alpha channel, if unused, is a solid color and therefore compresses really well. In my tests, having the unnecessary solid alpha channel added just under 10% to the exported video’s file size compared to RGB.
May I suggest renaming the lossless preset to “Ut Video 422” and renaming the alpha preset to “Ut Video RGBA”? (I feel 422 is too important to forfeit completely to RGB.) Those two presets should cover the bulk of export cases from Shotcut. After all, Ut Video is for pretty specialized purposes.
The 4:2:0 situation is more interesting. Ut Video does support 4:2:0 and it does create a smaller file than 4:2:2. However, Lossless H.264 (CRF 0) will create a file that is 33% smaller than even Ut Video 4:2:0. The major advantage Ut Video 4:2:0 has over CRF 0 is decoding speed for smoother editing and playback of multiple tracks. But if I’ve got that many tracks going on, I’ll be in proxy mode anyway. And when it comes to generating proxies, there are massive benefits from transcoding directly with ffmpeg because it becomes possible to specify a spline36 scaling filter with ordered dithering then follow it up with an unsharp mask and zscale colorspace conversion to make that proxy video clear and sharp as possible. I’m typing up a post for the Proxy Generation topic detailing exactly how this all works, but the takeaway is that going the extra mile with ffmpeg processing yields a perceptual sharpness gain of about 3x without having to increase resolution or bitrate or compromise colors. But you can’t get that processing chain from a Shotcut preset. All that to say, I’m not sure a Ut Video 4:2:0 preset brings anything to the party when Lossless H.264 makes smaller files and ffmpeg makes better-looking videos.
I agree that Ut Video 4:2:0 could have some useful specialized purposes. But power users will know how to tweak their presets if they want this or other formats. New users, meanwhile, wouldn’t know what to do with so many lossless variants anyway. Sounds like a “less is more” situation to me.
No, but I’ll test it when it’s out of beta. Please remind me when the upcoming version is out of beta. Did he do any changes to color in the next version, such as export presets?
Fixed color accuracy of lossless/Ut Video preset and use yuv422p format
You should test both the Ut presets (the one in the Alpha category as well as the one in Lossless) as well as anything else while it is in beta so that if there are any issues he could makes the fixes before the final release.
I don’t know what difference the answers to these questions makes. There will always be a small amount of rounding error due to the use of floating-point coefficients in BT.709. In my experience +/- 3 digital values in 8-bit video is as close as it gets.
I have not found any other color errors in the latest beta version of Shotcut.
My first question was me asking because I am not tech savvy. The output numbers you noted there for ProRes and the Ut rgb24a preset were identical so I was wondering if the difference in numbers with this beta’s Ut Lossless preset meant it was still off.
My second question was me wondering if this once and for all settled the color issues that were you noting Shotcut had which is why this thread exists in the first place. You were also talking about a separate program you were working on in regards to the colors I believe.
Sorry I didn’t reply sooner, chris319. The answer is contained in the write-up I’m doing on optimal proxy codecs within Shotcut, which I had hoped would be done long before now. But it’s going to be delayed a little more because I recently discovered DNxHR is available as a profile under the DNxHD codec, and I want to give DNxHR a chance to face-off with ProRes.
The highly subjective “3x sharpness gain” figure is based on a colorist workflow. If colorists are going to grade on proxies, they need to see clear distinction between shadow, midtone, and highlight to know what the grade will do to the full-resolution originals.
When I did a default scale of 4K or 1080p footage down to 640x360 or smaller, there were so many pixels averaged together in the downsize that all contrast within those averaged pixels just blurred together. A colorist cannot grade on mush.
By using the highest quality scaler along with dithering (where useful) and unsharp masking, the distinction between shadow, midtone, and highlight comes back to a usable level. Since we’ve gained in essence three colors (contrasts) where there was originally just one blurred color, I subjectively called that 3x sharpness gain. It is not scientific at all, which is unusual for me, but I’m not aware of any other way to quantify sharpness comparisons between images of different resolutions. If someone disputed my logic, I would probably agree with them.
Update: I was still using zscale when I wrote that 3x figure, before running into the Red Shift Problem. Now that I’m using libswscale instead, I would say the post-processing chain achieves 2.5x sharpness gain over defaults. zscale does hold better color at high-contrast edges when it works, but it doesn’t always work. In fact, throw a patch of bright red in the image and scale down to really small in 4:2:0, and it will always fail.
You can check horizontal luma resolution by emulating a square wave as in this test pattern. Keep in mind, though, that 4:2:2 will drop every other chroma sample horizontally and 4:2:0 every other sample horizontally and vertically.
The scale vs zscale situation is very situational.
The zscale bug only happens in 4:2:0 or 4:2:2. If you’re able to up-sample or operate in 4:4:4 or RGB, it’s fine.
If the zscale bug was fixed, I would be back to it before nightfall.
For the case of creating small proxies in 4:2:0 like I’m doing, it kinda makes scale the winner by default because zscale disqualified itself. But for photographic purposes in RGB, zscale would be fine.
Here’s an animated GIF I put together to demonstrate the problem. Sorry the source video is not a great work of art, but this is the video where I happened to notice the problem in the first place during testing. The source video was 4K and I scaled it down to the proxy sizes shown at the top of the GIF, then blew them back up to full-screen preview and took crops of the red fire hydrant. Notice how the left edge of the hydrant shifts. Naturally, the smaller the proxy, the bigger the shift appears when expanded up to full-screen preview. The shift of the red plane is so severe that it changes the overall brightness of the entire image. The 4:4:4 version is the only one that’s true to the source.
Whether that shift is enough to discourage someone from temporarily using zscale totally depends on their requirements.
The output numbers you noted there for ProRes and the Ut rgb24a preset were identical so I was wondering if the difference in numbers with this beta’s Ut Lossless preset meant it was still off.
