wolfpld / etcpak

The fastest ETC compressor on the planet
Other
229 stars 41 forks source link

RGBA vs BGRA #32

Open BastiaanOlij opened 1 year ago

BastiaanOlij commented 1 year ago

Hi,

I'm trying to figure out an issue that we're having where it seems that the ETC compression routines are expecting BGRA input. I'm not ruling out that we are doing something wrong later on in the pipeline and assuming the decompressed image is in BGRA format and thus resulting in it displaying wrong.

Can you confirm whether CompressEtc2Rgb and CompressEtc2Rgba expect data in BGRA format?

Cheers,

Bas

wolfpld commented 1 year ago

I don't remember. If it fixes things for you, then it is probably what's required. You can verify by following the PNG decode path, which explicitly calls something related to bgra conversion (quite unnecessarily, but it's too ingrained into the code now).

BastiaanOlij commented 1 year ago

Thanks @wolfpld , I guess the question here is, is ETC internally BGRA? Ergo when we supply RGBA data, does ETCPAK convert it to BGRA and save it as such?

I have a suspicion that us loading ETC data and then telling the GPU the data is RGBA, that this is actually where it goes wrong, not in saving, and us flipping the R and B channels on save just works around the issue. Is there any place to find good info on this?

edit hmm, no thats probably not it, we're using VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK so you'd assume Vulkan is treating the data as RGBA

wolfpld commented 1 year ago

There is only one way to decode the ETC data (i.e. transform the ETC binary stream into vec4 RGBA fields in shaders). Only input data to etcpak matters.

BastiaanOlij commented 1 year ago

Then i am happy that our changes in Godot are doing the right thing, does then indeed seem to be the input to ProcessRGB(A) is BGRA.