Page MenuHome

Dither does not work properly with some image formats
Closed, ArchivedPublic

Description

--- Operating System, Graphics card ---
Linux Mint 64bit, gtx 460

--- Blender version with error, and version that worked ---
Works with 2.65a release, bug occurs with buildbot and manual git build.

--- Short description of error ---
In recent Blender builds, with compressed image formats like JPEG or all the video codecs the post-processing dithering does not work anymore.
Formats like png work indeed. At first I thought that the missing dithering comes from the conversion to 420 YUV, but as you can see in the test file I have used a simple black and white gradient and if you render, save the result as jpeg and open it, you see that the banding is there. An image with 2.65a will be properly dithered.

Besides, the dithering process seems to be applied before conversion to the output format's color space. I think it is very important that that the dithering pattern is applied in correspondence with the chroma sampling pattern that will be exported because dithering of chroma planes in Blender's RGB space will always be destroyed if you export for example to DNxHD 120.

--- Steps for others to reproduce the error (preferably based on attached .blend file) ---
In the attached blend file, render the image and then save it once as jpeg and as png. The png file will be dithered, while the jpeg file will only have some sort of biased dithering.

Event Timeline

This is a problematic issue... since we do color management, all this conversion work goes via color operations using the OpenColor library.
It might well be that dithering is not supported there. Will ask Sergey to investigate it.

Checked the code and your files. There's no difference in how dither is applying on image when you save png or jpeg (or any other format). This is difference in codecs: PNG is lossless and will preserve all the details, in contrast JPEG is lossy and designed to save look&feel of large areas only and details could be eliminated by compression algorithm.

I also compared results of 2.63, 2.65 and current trunk and they seemed to be identical.

It could be some differences in algorithms inside libjpeg or ffmpeg (or whatever you use for comparison) and we could not affect on them.

For now i could not see anything we could solve here. If you think there's a bug here please provide file which demonstrates it. And use only builds from blender.org and builder.blender.org for comparison. No builds from repository or graphicall please.

Sergey Sharybin (sergey) changed the task status from Unknown Status to Archived.Jan 21 2013, 10:53 AM