I’ve got a new problem now, and I’m not sure what forum to put this under since I am not sure if it’s a rendering issue.
So I rendered out my model with an emission shader that has vertex paint attached to it. It is rendering in PNG. The issue is that the color of the bumper needs to be [255, 0, 128], but the program that my co-workers are using to read the images for whatever task they are using the renders for are getting other values from the image as well. They are also getting [255, 2, 130], [255, 1, 129], [255, 1, 129]. It kind of looks like this:
I need it to not be dotty. I don’t understand if it’s Blender’s issue, or if it is an issue with images being pulled into their program (it uses opencv and matplotlib). Any help on this will be greatly appreciated, and if you need more info from me in case I wasn’t clear on anything, please let me know. I’m not an expert in Python or Blender’s rendering system in general (but I’m getting there!).
No, it’s not the color. The image you’re looking at is what those Python libraries are showing it looks like. Unfortunately, I can’t share the .blend file because this is for my work, and I’m trying to help them figure out why their Python program is showing my renders like this. To be honest, I don’t know what the yellow dots mean. My co-worker told me it is all the pixels of the color of that bumper that aren’t pink [255, 0, 128]. I will post an image of the render below.
Also, so you know, it’s not just the bumper that this issue is happening to. It’s happening to all the colors, the bumper is just one example. So because of that information, I first thought maybe it was the anti-aliasing creating gradients in the color because it renders out as a rastor image, but when I turned in a test render with the anti-aliasing turned all the way down, it still showed all those dots in the Python scan/render/thing, and now my edges are all crunchy and unpleasant.
Ok, so I just tested now if it was an image compression problem, but the values that I’m getting in Paint (it’s the only image viewer on that shared computer) are still varied. They aren’t all [255, 0, 128]. So it has to be some sort of output from Blender that is causing the pixels to become different colors.
“I can’t provide .blend” is a bad excuse. Prepare one you can share.
You’re wondering if it’s an issue in what Blender puts out, so what are you expecting any outsider to do about it without a test file? There’s also the reason why anyone would be so interested in your problem. One such reason could be to find out if Blender is behaving like it’s not supposed to and would need to be reported on the bug tracker, which in turn require a test file and that it’s tested on multiple systems.
Try and answer other people’s questions around the forum a few hundred times when there’s only a cropshot to work with, and you’ll soon figure that it’s not the problem description that gives answers, it’s getting the information they were using to get the problem produced. That translates to using visuals when explaining something and uploading a .blend for actual troubleshooting and getting visuals back. The rest is a waste of time, because “simple” problems have a lot of possible causes, and if the poster is an advanced user, the cause for the problem won’t be obvious. Either way, the example file is the most important thing to actually work the problem.
Since I’m under an NDA, this file is as bare bones as I can get it. It should have all the necessary parts to what my work typically looks like. My boss has given a request for you or anyone who also would like to take a look at this. We need a detailed description of any work that you do on the file. A list of all the steps you took to reach the end product would suffice. They would like to know all the steps so that I can relay them to share with the rest of the team.
Some information that is helpful: the color output of the pink and blue need to be the same color throughout on the output file. So for example, the pink is [255, 0, 128]. There can be no pixels in the output that are different, they all have to be that color. I don’t know why, it just has to. You can try any output image, targa, png, jpg, it doesn’t matter. If I have render settings in the scene that are causing the image to lose its quality or cause the pixels to have different values, please let me know. I didn’t create the scene, I have just been manipulating it.
Blender uses multilayer openexr format internally. When the render is saved by the user or automatically to another format, it does the conversion on output.
Looks like 8 bits per channel causes fluctuations in the values, mostly lower than 1 percent but some above. Don’t know why, floating point errors might have something to do with it, but it does. Saving the image with at least 16 bits gets rid of that.
Edit: the values fluctuate because dithering is on, which adds noise
8 bit and 16 bit images, when looking for a 0.001 value difference.
If the goal is to render flat colors, there are many settings that don’t make sense. Object properties -> cycles visibility: camera to only have the object visible to the camera and not other objects. Per material that is done with the light path node: is camera ray socket. Only showing an object or a material to the camera makes sure those don’t affect other objects or materials.
Very high bounces. Flat colors would need 0 bounces, direct light only, so wouldn’t need to set clamp indirect and filter glossy settings either. Those also require much less samples.
How do I change the light bounces? I believe in this case I don’t need any at all, since all I need are the emission colors. I have a separate render file that’s specifically for rendering high resolution images with materials; this file was a copy of it, and I only knew how to change the materials for the objects in the scene.
Right, found the cause. Render properties -> post processing: dither is set to 2. It adds noise to get rid of banding, which in this case also causes the subtle value differences in the conversion. So makes sense now but it wasn’t my mind that went there.
It’s rarely needed and off by default so didn’t thought to check it. I linked my own post elsewhere and was thinking out loud how surprisingly inaccurate the conversion is and got asked if dithering was on. I did check the reports and didn’t find anything, and it kept bugging me that floating point errors would cause that, as those would be in much less significant bits.