why are my sprites washed out?

Shadowphile

Rather than try to describe I've just captured various IDE shots. I have a ViewPortTexture cast onto a mesh sphere for a panoramic view. The viewport has a background Sprite and an AnimatedSprite using a SpriteSheet. The pictures NoBG and WithBG show a zoom of the spritesheet below and the projection onto the sphere in the 3D viewport. The projection is much brighter than it should be. I've also shown the shader code I'm using and the Inspector for the Pano mesh sphere material

.
I've tried everything I can stumble across. please let me know what is going on!
thanks

edit: ok, I started doing goofy things and when importing my image I changed HDR as sRGB to true. Not sure why this works though, but I suspect the process steps I used to assemble the sprite sheet from separate PNGs monkeyed with the colorspace.

xyz

Shadowphile Force srgb/linear conversion on the texture by adding source_color hint to the uniform declaration

Shadowphile

xyz thanks but that isn't available in 3.6. My sources are JPGs.
I never had this problem when I was loading a texture directly into a uniform sampler2D but since I've changed to using a ViewportTexture I'm running into what seem like colorspace issues. My original post was only about the Sprites being too bright but now that my script is loading images dynamically ALL of my main background images are loading too bright looking, I can't offer more right now, everything is still kind of broken since I'm refactoring so much.

xyz

Shadowphile It is available. It's called hint_albedo. Check the shading language reference in the docs.

Shadowphile

xyz
I'm already using hint_albedo.
I thought I resolved this because at a glance my brightnesses were all as expected but today I realized that everything is heavily corrupted but it's only obvious in gradient regions.
I'm running into a similar problem project wide now. My images looked fine when I was directly inserting StreamTexture-imported images into the Uniform but now that I've moved everything to subviewports they are all wrong.
Here is before and after: My source images are all JPGS with high-quality compression (95-98).

I imported my JPG as an Image and now creating my textures for display using this:
(btw, it works no better than Importing as a StreamTexture when using the method below)
IMG = Image.new()
IMG.load(g.ImageBank[diff])
if targetnode == 'background':
IMG.convert(Image.FORMAT_RGB8) <--- 'background' means a JPG, otherwise I'm using PNGs for overlays.
else:
IMG.convert(Image.FORMAT_RGBA8)
TEX = ImageTexture.new()
var flgs = Texture.FLAG_FILTER
flgs += Texture.FLAG_CONVERT_TO_LINEAR
TEX.create_from_image(IMG,flgs)
IMG.lock()
SetTex()

Here is my shader that TEX is being inserted to (via the subviewport TextureRect holding the ImageTexture):
shader_type spatial;
render_mode unshaded;
uniform sampler2D pano_tex : hint_albedo;
uniform float uv_size : hint_range(0.01, 10.0, 0.001) = 1.0;
void fragment() {
vec2 UV_Scaled = UV * uv_size;
vec3 tback= texture(pano_tex, UV).rgb;
ALBEDO = tback;
}

I am wondering if I tried to use COLOR instead of ALBEDO would make a different, although I have to change some things in order supply the correct format to the shader. Since the surface that is displaying the image is a projection onto a sphere, I don't want any albedo-like behavior anyway. (I'm assuming albedo refers to a surface that reacts to the lighting around it; 'unshaded' should be taking care of that anyway.)
I also tried importing the image as a PNG so there would be zero compression artifacts in the original image but it looks exactly the same.
Looking at the two images above it seems like compression artifacts, not colorspace, but I'm can't be sure of that with 8-bit images.

xyz

Shadowphile Can you post a minimal reproduction project?

Shadowphile

xyz
Yeah, I think I can work that up from scratch. I will repost with that later.

Shadowphile

Turns out even the simplest setup still has the same problem, not even using subviewports anymore.
However, when I tried the GLES2 shader the problem went away.
Here are some snapshots of what to expect when running it. Original.png is a screen-shot from my original project before I started trying to refactor my graphics pipeline, the other is what you should see when you run the project attached.
Considering that the original project looks good with all of it's complexity but a trivial example doesn't, it's probably one stupid setting somewhere :/ (or a bug)
From my original project when things looked ok:

Screenshot from the attached project:

MVP:

testview.zip

6MB

xyz

Shadowphile Enable: Project Settings > Rendering > Quality > Depth > HDR

Alternatively if you for some reason don't want to use floating point framebuffer, you can linearize the texture itself and remove hint_albedo from the shader. This should improve things considerably as the engine wouldn't need to do the whole srgb->linear->srgb conversion within limited precision of only 8 bits per channel. If you use Photoshop this can be done by converting the image to a custom linear color profile and resaving it. Go to Edit > Convert to Profile, for RGB destination space choose CustomRGB, and set the profile gamma to 1.0 instead of default srgb gamma of 2.2.

Shadowphile

xyz
I was thinking worst case I might end up exporting linear images from Blender.
Thanks for the pointer to the HDR setting! It works in the simple demo I sent but it totally screws things up in my main project, I mean the cursors; even the window won't toggle between windowed and full-screen correctly. That last makes no sense at all....

Shadowphile

Here is the same demo (with Quality-HDR set) but setup with subviewport; the output is totally gray.

testsvp.zip

6MB

xyz

Shadowphile but it totally screws things up in my main project, I mean the cursors; even the window won't toggle between windowed and full-screen correctly

Make another mrp that demonstrates this.

xyz

Shadowphile Here is the same demo (with Quality-HDR set) but setup with subviewport; the output is totally gray.

There is no texture assigned to the TextureRect at all in that second mrp. You get the gray since nothing but the clear color is rendered in the viewport. Once you assign the texture, the thing looks as expected. Note that you need to enable hdr for the viewport as well in the inspector. Otherwise you still might see those posterization artifacts in fine gradients, as in that case the double conversion from/to srgb inside limiting 8 bit bandwidth would still happen.

Shadowphile

xyz
While investigating I've been making lots of changes back and forth and that has made this journey rather messy.
I did a lot of playing around and found some issues that I was able to resolve: (buggy kind of issues)
-Although I no longer had a PNG file in my resource folder, it still existed as a .stex in the .import folder and I was still accidently referring to it when loading using the Image.load('resourcename'). That was REALLY throwing me off! Godot really needs to keep obsolete import files cleaned out, although there's probably a reason they are kept around.
-My image was still too dark in my main project despite looking ok in the demo project. I found two .stex files for the same file in the .import folder and couldn't figure out why until I did a search and found a duplicate of the JPG archived in a subfolder I wasn't using. I got rid of the subfolder and suddenly everything looks good! Not sure if there was a problem with having the same file twice in two different places in the RES folder; maybe a user-case the developers didn't think anybody would actually do since you would normally just refer to the same image, not import two copies. User's are really good at doing crazy things the developers assume nobody would attempt because 'that makes no sense!' lol.

Here is what I have found working now:
1) Disable 'sRGB' when importing an image. JPGs work fine also. This is a must. (Detect sRGB may also work, which is the default)
2) Enable HDR in Quality in project.
3) Turn off HDR in the Viewport.
4) This is the import function I use for all of my images: It turned off the convert_to_linear flag.

	var diff = SelectBG(variation)
	IMG = Image.new()
	IMG.load(g.ImageBank[diff])  #"res://0300s/N0315_OfficeShopDoor/BG0315.jpg")     #g.ImageBank[diff])
	IMG.convert(Image.FORMAT_RGBA8)
	TEX = ImageTexture.new()
	var flgs = Texture.FLAG_FILTER   (do not use flgs += Texture.FLAG_CONVERT_TO_LINEAR)
	TEX.create_from_image(IMG,flgs)
	g.PB.get_node("BG").texture = TEX
	IMG.lock()

4) I added a simple gamma adjustment in the shader. I'm testing some night scenes with dark gradients on the horizon which were hard to get smooth even at the render stage in Blender but even they look good now, no banding at all. I could probably use a more sophisticated color-space adjustment in the shader but it's looking fairly good now.

    vec3 tback = texture(pano_tex, UV_Scaled).rgb;
	tback = pow(tback, vec3(1.0 / .6));

So for now, it's looking good!

xyz

Shadowphile Manually loading images may be needlessly complicating things. Instead, assign/import bitmaps directly as textures and then create images from those textures if you need to access the pixel data on the cpu side. I think I already mentioned that. ImageTexture::create_from_image() may still do a sneaky srgb->linear conversion, depending on image's pixel format.