I drew a cube in the 2D drawing tool and printed it out as a png file, and imported it into the blender using the Shift + A, Images as Planes function.
But here is the problem.
The imported image is lighter than the original image.
Please see the attached screenshot.
The image opened in Paint on the right is the original.
The Reference object next to it accurately displays the original image.
However, the three Image as Planes objects on the left are displayed lightly.
Perhaps the texture responds to the environment, but I wonder if even objects with shadeless and emit options react to the environment.
How can I solve this problem?
Change your display device to “none” to see the image you want.
This is kind of a weird situation-- there are probably multiple factors interacting. First, Blender isn’t applying the view transform to the reference empty, which may be a bug (or may not be, I’m not sure the best way to handle a situation like this.) Second, your image editing application and Blender and handling color management at separate levels. Your image’s color is all 0,0,0 black, so it’s the same in sRGB as in linear color. But once you modulate by the alpha, you end up with a gray image. Blender seems to be applying the view transform to the final layer, while your image editing application seems to be applying it to the individual layers.
That’s also why the empty display may not be a bug. At this level, Blender is probably handling things as separate layers: apply view transform to entire preview, apply view transform to reference image color (which is 0,0,0 black, no transform), then mix between the two using reference image alpha, which turns that black into gray, which never gets transformed.
Edit: I may be kinda wrong about Blender not applying the view transform to the empty. After all, the underlying color is black. It’s just not very clear what Blender should be doing.
Edit2: Man, gamma is a non-stop clusterfuck, and now that haven’t had CRTs for about twenty years or more, isn’t it time to get rid of it? The only reason we have to worry about this is because it was baked into jpgs intended for display in Win 3.1.
That method has its limitations.
The Color Mnagement > Display Device > None option causes the black and white alpha textures to appear the same as the original image, but for color images, the colors appear darker.
There are plenty enough bugs to keep devs busy. Considering this is kind of reasonable behavior-- it’s hard to really say how things should work-- I would personally save my bug reports for something more obviously wrong.
I know, you don’t want to set display device to none, because then you need to do your gamma correction manually. I think it might work if you run the sRGB->linear transform on the alpha, but I haven’t tested that (I often get order of operations mixed up when just thinking this stuff through, I have to sit down and test what I’m saying.) The easiest way to run that transform on your alpha would be to write it to a color channel instead so that you could read it as sRGB data. (Yet one more useful set of nodes that we don’t have: color space conversions. You can make them manually but it’s a pain and I doubt they have the same performance as native nodes would. Instead, we get a square root node. Sigh.)
In all of this software, colors look the same as the original image.
But the only one in Blender I’m having a problem with the colors of the cubes appearing bright.
I can choose the Display Device: None or View Transform: Raw option for the cube, but I think that’s not the correct solution because it darkens the color of the color image (blender 2.81 splash image).
Changing the color space of the texture doesn’t actually affect alpha-- alpha doesn’t go through the transform. That’s why I was saying, try using a color channel instead of alpha: to get the color transform working on it. Like, write your alpha to the red channel, then read the red channel for your mix factor instead of your alpha.
I understand your explanation not to use the mix factor directly because the alpha channel is not affected by the color transform.
But I don’t know how to write alpha to the red channel.
How do I connect the nodes to do that in the shader editor?
That’s not something you do in the shader editor. It’s something you do in your image editing application. If I was doing that in GIMP, I would change the color of the transparent image to red, place over a black background layer, then flatten the image, which ought to give me the alpha as a red channel image instead.
And ertainly linear color and gamma seem to be non-stop clusterfuck as the bandages say.
Since CRT monitors are old-fashioned artifacts, blender-style color management would be a standard, but many image software still use Photoshop-style color management.
I feel a lot disappointed that Blender doesn’t provide easy compatibility in this area.
I will study more about gamma and then test how to use alpha images created outside of the blender in the blender.
However, if someone knows a clear workflow in this situation where data is input / output between software using different color management, please write a thread here.
