Grayscale png not properly loaded

Issue details

I want to use a grayscale image (with palette) like this one: image | Format detail.

When I load this image, Pixmap.Format is set to Alpha, good! But in my shader, when I sample the alpha channel, it’s just white. I tried with LuminanceAlpha and Intensity on all channels and it’s not working either.

When loading image with Texture(FileHandle, Format, Mipmap), if I force format to be RGBA8888, it works in the alpha channel of my shader! So I have to force the RGBA8888 with a grayscale image (wasting memory).

Version of LibGDX and/or relevant dependencies

1.9.3-Snapshot OpenglEs3 enabled

Please select the affected platforms

• Android
• iOS
• HTML/GWT
• Windows
• Linux
• MacOS

[tommyettinger]

So, as far as I can tell, this is a valid issue still, but there’s nothing we can do about it… Optimizing for GPU memory usage is not easy. As far as I can tell, there isn’t a generally-portable way to load a single-channel image into GPU memory on all platforms (HTML doesn’t support GL_RED).

But if you want grayscale images for file size reasons:

If you’re using PNG output color mode 0 (grayscale) or 4 (grayscale with alpha), it seems like PNG compressors can’t do as much for file-size with those, and color mode 3 (palette, or indexed color) generally makes a smaller image as long as there is at most one transparent color. So the only reason to prefer 8bpp grayscale over 8bpp palette is if the image is so tiny that the palette takes up a significant part of the file, and since we had better be using texture atlases, that should never happen in a real game. Shaders won’t ever interact with a PNG directly; they only see what has been loaded onto the GPU, and if the PNG was palette-based with 256 shades of gray, the GPU will have the same contents as if it had loaded a grayscale PNG, if both using the same format.

I am able to load this 200-something-color paletted atlas using RGBA8888 format specified in the atlas, and at least that works on HTML and desktop. I might be able to use RGB888. This does use more memory on the GPU than a single-channel format, but the portability is important for me.

I typically use PNGOUT to losslessly compress atlases. It’s kinda slow, but a lot faster than zopfliPNG, and according to its readme, zopfliPNG only gets 0.5% smaller file sizes typically.

Back to the issue at hand, memory usage, I think xoppa answered this well 4 years ago:

I don’t think there’s a good solution for this, as in: we cannot abstract this incompatibility away because it requires modifying the shader. GLES3 adds GL_RED though, so I guess the fix would be to add GL_RED support when gles3 is used (the html backend doesnt support gles3 yet). It would be up to the user to modify the shader accordingly then.

There hasn’t been any PR or similar activity trying to implement the complicated-looking swizzle code, but if someone was willing to write one without breaking compatibility, I would absolutely merge that PR. I’ll leave this issue open for now; it isn’t completely resolved without someone maybe partially trying to implement swizzling on GLES 3.0 and reporting back whether it’s feasible.

[BenMcLean]

Someone who is not able to modify a shader has no business developing games, tbh.

Come now, that is not fair. GLSL is a very odd and finicky language and requires understanding some concepts that someone who makes simple 2D games may have never encountered before. On top of this, WebGL only supports a subset of it’s features.

I myself have been getting help making modifying and tweaking shaders for the first time over the past few months. I’d say one definitely doesn’t have to already know how to modify a shader to start developing games.