antialias problem save as png ?

Support Compositing and Post Processing
1

I noticed this problem before and I can’t discover why this happens.
First picture is saved as .png via compositor,
The second picture is a screen shot of the compositor and I pasted it in Microsoft paint, and saved it there.
You see that the edges are softer in the second one.
Any idea ?
[ATTACH=CONFIG]406999[/ATTACH][ATTACH=CONFIG]407000[/ATTACH]

2

from using “Microsoft Paint”
i am GUESSING!!!

you are using one of the windows operation systems
What One ??? that is any ones guess

  • i can not read your mind so…

xp?
Vixta?
7?
8?
8.1?
10?
– or win98

nor do we know if you are using a old CRT tube screen - i still have 2
or a cheep lowres 12 bit lcd
or a high end plasma or high end lcd

nor do we know if you are using your 3d card for “Windows Explorer”
nor what you set the graphics to " antilias "
1x?
2x?
4x?
nor if it is set to use “per program” ?

it “looks” like you resized the image – that will "soften it "
or the lcd screen settings is softening it ?

3

The compositor preview (if that’s what you c/p-ed) may be scaling you final image. Just a 1px difference can be enough to trigger some filtering/blurring.

BTW, it’s better that instead of c/p-ing into Paint, you use Ctrl-F3 (Window/Make Screenshot) so we can see your entire interface.

4

Thanks, here a bit more info:

I made a video on youtube:

Some specs:

More specs in pics:
[ATTACH=CONFIG]407020[/ATTACH][ATTACH=CONFIG]407021[/ATTACH]

5

My apology that I need so many words to explain the problem, and still I realize, so far it might not be clear.
Here clearly formulated the problem itself:

  • I render a scene, and in the preview ( uv/image editor:compositor) I see the result. And I think “Ah that is nice, Lets save it”
  • I save the picture in png, and I look back with several image viewer, and I think “Oh what happend with those edges”?
    ( - So I did a test to make a screenshot, and compare. and indeed… it’s different ).

I think it might have something to do with one of the following:

  • alpha over,
  • color ramps on constant
  • convert premultiply or not. ( no idea what it is yet ).

Blender saves the render, and at that time something goes wrong.
I tried RGB, RGBa, 8 and 16 bit.

6

Did a few more tests, and it seems that this problem occurs easily if i use color ramps set on constant, or to tight. Not sure what it means. ( just find it strange i see difference in the uv/image editor and in the files. By the way I tried other files, jpg, jp2, tiff, and that doesn’t matter.

7

Remember that, in preview, you are seeing the accurate digital information as produced by Blender itself. It is, at this point, "a vast and detailed collection of floating-point numbers.

When you save the file to .PNG or to any other “image file” format, many things happen:

  • The data is quantized into integers of a certain size.
  • Gamma-correction is applied.
  • The data may be mapped to a different color-space.
  • Alpha pre-multiplication may occur.

In other words, the data is prepared for presentation by an utterly-stupid :wink: graphics file viewer. (Which is precisely what needs to happen, to create a “portable” graphics output file.)

And then(!), the “stupid graphics file viewer program in question” can … uhh … do as it pleases.

FYI: Blender does provide two industry standard output-file formats, OpenEXR and MultiLayer OpenEXR, which are specifically designed to capture “raw” CG-output data exactly, without loss or transformation of any kind. These file formats capture the actual digital output, in all its floating-point glory (and precision), “losslessly.” (Industrial Light & Magic developed the initial format, and Blender Foundation(!) defined what came to be the “MultiLayer” standard extension.) If you’re doing anything in multiple steps where you need to be sure that “what you calculate(d) is exactly what you get,” you must use these formats.

8

@sundialsvc4
Thank you, your answer is very clear to me. Up to OpenEXR…
Checked it quickly… and yes… you are right. Great… problem solved.