Add Alpha from Grayscale import option to Texture2D

[Calinou]

This can be used to import textures that are on a solid black background and use them for VFX.

This also adds and exposes Image::get_format_with_alpha() and Image::get_format_without_alpha() static methods for convenience when working with image formats.

• This closes Add "Alpha from GrayScale" texture import setting godot-proposals#5247.

Testing project: test_alpha_from_grayscale.zip
_{Sprite from Kenney Particle Pack, licensed under CC0 1.0 Universal.}

Preview

@Exyde @FyiurAmron Can you confirm this has the expected appearance?

[FyiurAmron]

@Calinou GIMP's "Color to Alpha" does a different trick, it doesn't apply alpha from grayscale properly. To have it match the reference, you'd have to import the image as its own transparency/alpha mask. Then, the result matches the behaviour of your code perfectly:

tl;dr LGTM, I confirm your code does exactly what it should, +1.

BTW, what's with the brightness on your reference image? It's toned down vs what the actual images from the ZIP have, e.g.

?

[Mickeon]

BTW, what's with the brightness on your reference image? It's toned down vs what the actual images from the ZIP have, e.g.

Linear to standard RGB, judging by the gamma change.

[Calinou]

BTW, what's with the brightness on your reference image? It's toned down vs what the actual images from the ZIP have, e.g.

Filmic tonemapping with whitepoint 6 is used in the MRP.

[Mickeon]

That extra detail in is_compressed is very, very necessary

[clayjohn]

I'm not sure that this is something we need to have in our importer. It seems like a workaround for a very specific workflow. It seems the problem that this is solving is that users have assets that are in grayscale with no alpha since they are designed to be used as additive textures, but they want to use them as an alpha mask without making any changes to the texture in an external program.

I'm not sure this belongs in Godot asset authoring is something that is better handled by programs dedicated to asset authoring. I think it makes sense to include common operations in Godot or things that are required for places where Godot may differ from the asset authoring tool (like flipping the green channel in normal maps), but I don't think we should add every image operation just because we can.

The underlying proposal doesn't seem to have gained much interest either in the 2 years its been open. I have a feeling it is something that is very niche.

[Zireael07]

better handled by programs dedicated to asset authoring

The problem with that line of thinking is the same as with thinking "just make assets that line up with Godot's default forward axis". Namely, a lot of devs use freely available assets (e.g. from asset stores, Open Game Art, or other free asset sites) and do NOT have ANY influence on how the asset is made

[FyiurAmron]

@clayjohn

It seems like a workaround for a very specific workflow.

That has been addressed directly in godotengine/godot-proposals#5247 (comment)

It seems the problem that this is solving is that users have assets that are in grayscale with no alpha since they are designed to be used as additive textures, but they want to use them as an alpha mask without making any changes to the texture in an external program.

Yes, that's exactly what it's solving. See above, ditto.

I'm not sure this belongs in Godot asset authoring is something that is better handled by programs dedicated to asset authoring.

This, by itself, belongs to neither, and in ideal situation can be handled by either.

I think it makes sense to include common operations in Godot or things that are required for places where Godot may differ from the asset authoring tool (like flipping the green channel in normal maps),

Yes.

but I don't think we should add every image operation just because we can.

Yes, but this is not "every image operation". Ditto. Many assets and workflows are made with this assumption in mind, and, arguably, that's why e.g. Unity provides this option. Code-wise, it's trivial to implement (as @Calinou clearly showed) - meanwhile, batch-processing the assets to include additional unneeded data (4th channel that is implied from avg. pixel brightness) is tedious and prone to errors.

The underlying proposal doesn't seem to have gained much interest either in the 2 years its been open. I have a feeling it is something that is very niche.

See above. If 10 people voted on having something that required literally one operation (equivalent of 1 LLOC more or less) in a loop and some glue to implement, IMVHO that's the correct ratio of need-vs-effort. Also, we already have the code, courtesy of @Calinou , so actually the cost is near-zero ATM; however, the question here would be: should we go and remove all features in Godot that didn't gather more than N votes in proposals during T months/years?

Also maybe let's keep the code/implementation-related discussion here and the feature/idea discussion in the proposal discussion (instead of introducing the latter here in MR)?

[FyiurAmron]

@Calinou are there any blockers/prerequisites for this (IIUC, #88763 was, but it's merged already?), or is this ready to be merged?

[FyiurAmron]

@Calinou ^ bumping the question above for great justice :) Is there any help, be it testing or coding, needed here?

[BlueCube3310]

Needs a rebase, but otherwise looks great

[Calinou]

Rebased and tested again, it works as expected.

[BlueCube3310]

Approving for import