I take a UV-Sphere, render it without a “world” (on black - all default settings like OSA 8) as png or tif, import it into
Nuke (the compositing app. from The Foundry) or Photoshop and look at the alpha.
Inside the sphere there are non white pixels!!! That means the matte is not fully opaque!
The viewer from Blender shows me all pixels fully white!
Especially if I import it into Photoshop, crank up the contrast of the inverted alpha channel, I can see lines of the polygons! (The same happens with a simple cube!)
It´s funny - even in the fill I can see the artifacts or edges of the polys!
Mesh “Auto Smooth” dosen’t change the problem. (Was off in the posted .blend file)
Yeah I see them now - I was adjusting the contrast wrongly. Now I remember, I’m sure this was one of the other reasons I stopped using the internal renderer because I was getting lines in my composites. I can’t recall what setup I had that would affect the alpha this way but it definitely showed these symptoms. I tested the same scene with 3delight (Renderman) and it comes out clean after contrast adjustment so it’s definitely a Blender issue. Smoothing, subdivs, dithering, nothing works - dithering makes it go fuzzy though.
The left one is the 3delight image that underwent the same contrast adjustment as the Blender output on the right.
Submit to the bugtracker? I didn’t know about this at all, and I’ve been using it with photoshop for awhile. I haven’t used the output for masking, just rendering to the premul or key option with object rendering.
When you submit it, make sure to try and keep the points in mind, which are necessary for a proper analysis of the problem. Hope this gets solved, though!
I found out about another strange behaviour:
If I try to see the problem in the comp tree within Blender (as a render layer as input and with the use of a color ramp), the problem doesn’t appear!!
But if I render this to disk (png, tiff) and import this as an image, then the image and the alpha is damaged!
So it’s maybe more an image writing problem than a rendering problem.
I replaced the .blend file with the composite nodes as shown below:
Yeah, it seems to be having trouble writing the alpha channel to the file. There is definitely a difference between the written file and the render:
It looks like a rounding error. Internally, the values are floating point so when it is outputting to an 8bpp image, it is rounding up instead of down. The alpha values in error are around 0.996 and one unit in 8-bit is equivalent to 0.00396… in 32-bit. I’ve seen some Math.round functions that always round up when it should only round up if the value is more than half way between two units.
Damn, Should have finished reading OSX’s reply. Anyway there’s still some good stuff in here:
OK, time for round 2. Pay attention to what you can actually see, not what you think you’re seeing. The real test is to load another image behind it and see if any of that image shows through (gradients with loud, saturated colors work exceptionally well for this purpose). Does it show through?..I didn’t think it would so, problem solved.
On the other hand there actually is a loss of quality in the alpha which I believe has to do with floating point conversion from 32BPC to 8BPC (your alpha ends up being 0.99609375% opaque rather than 100% opaque which is not visible in the end unless you go multiplying alpha values which is another matter entirely). You can side step this issue by NOT rendering to an 8 bit format such as .png (Blender will not output .png in anything other than 8 BPC). If that minor yet inperceptible .004% bothers you then step your renders up to 16 BPC via the OpenExr format with “Half” type option selected.
Anyway, the gist of the matter goes something like this: 8BPC images span a range of 0 to 255 while floating point images span a range of 0.0 to 1.0. When the conversion from float to 8 BPC takes place the valueof 1.0 (fully opaque floating point) gets divided by 255 (fully opaque in 8BPC) while fully opaque 8BPC actually cantains 256 gradations of color (0 to 255, not 1 to 256, remember?). So, lets do the math: 1.0 / 256 = 0.00390625 * 255 = 0.99609375. This should tell you that 1/256 is being lost in the conversion which can be accounted via the loss of the zero when counting from 0 to 255. You can test this by loading an image rendered as .png into an image node, connecting to a viewer node and Left Click dragging across areas that should be totally opaque which will show you a float value of 0.996.
If you’re only rendering stills you can change the image output type after rendering to a lower bit depth format BUT, since it has already undergone float to 8 bit conversion before changing back to float, the alpha problem will remain. The only solution is to select a higher format B4 rendering begins.
If you have a serious problem with this then the only way to solve it is 1.) Take the issue to ILM’s OpenExr board and hope that they’ll listen to you (don’t be surprised if your pleas fall on deaf ears cuz those guys are probably already aware of the issue and probably have it set up that way for some good mathematical reasoning), or, 2.) Beg Blender’s Development team to add support for higher bit depths than 8 bit for all formats capable of supporting these higher depths (such as .png which is capable of 24 BPC but, again, don’t be surprised if your pleas fall on deaf ears because the entire industry is moving toward OpenExr anyway. I have already discussed some of this with Broken - in a round about fashion - and discovered that there are some incredible hurdles to be jumped when dealing with legacy issues that no one is intrested in undertaking since it would detract from the development of new features and, again, the industry is marching toward OpenExr anyway). Then again there may be a dev who will sympathize but I seriously doubt this.
I am personally fond of .png myself but I do not render the format from Blender because it wont render 24BPC .png files.
