About the png importation format and the channels (8 or 16)

Question

Hello,

I'd like to understand something: in the doc, it writed the engine supports only 8 bits depth channels for the PNG format. I have make textures as 16 and 24 bits depth.
What happend if i stay with these values ? I mean, why do i need to respect the 8 channels quantity ?

Incogitant

Answer 1

Btw., where does it say Godot only supports 8bit/channel PNG textures ?

Here. But it is said that there is a limit to the precision of the import.

I have make textures as 16 and 24 bits depth.
What happend if i stay with these values ? I mean, why do i need to respect the 8 channels quantity ?

That is, nothing will happen, only the bits of color will be lowered.

Weinhardt

Answer 2

8 bit per channel is a severe limitation for some use cases. The PNG format specification includes 16bit/channel.

A png format with 24 bits per channel doesn't exist, at least not in the libpng implementation that's probably at the base of the engine. A 2D texture with 8 channels doesn't exist either.

I think there's a confusion about what a channel of a 2D texture is: a pixel of a 2D texture either has 1 channel (monochrome), 2 channels (e.g. for normal maps), 3 channels (that's RGB then), or all 4 (RGBA). There may be other colour codings.

Otoh the depth refers to each of these channels, how many bits it has to represent its value. 8bit would mean values between 0 and 255, or -128 and 127. Please be sure that you don't mean a 2 or 3 channel texture with 8bit per channel (=16 or 24bit per pixel), but really a texture with 16bits per channel, for instance a monochrome texture with integer values 0 to 65535 (or -32768 and 32767, both ideal for a height map), or maybe a normal map with 16bit floats.

So, first question's answer: nothing happens. You can't load a 16bit/channel texture if the loader doesn't support that. There be an error or just garbage. Second: you need to accept what the engine offers (*), or brew your own import routine, or search if someone with a similar problem has done so before and put his work to public use.

Hth a bit :-)

(*) Which is enough for by far the most use cases.

Examinant

Answer 3

It's 8-bits per channel, so a 3-channel RGB image would be 24-bits.

Icehouse

Answer 4

For some textures, i need to export them from Blender and i have this choice: 8 or 16.

I use always 16 and you said the engine doesn't open it ? I haven't problems in Godot. What i have in the screen below then ?

I accept the engines offers to me, i want just to understand the "why", because i see something differant and i wonder why to myself. This is not to make any critics to the engine.

Incogitant

Answer 5

No, you said the engine only supports 8bit/channel.

'd like to understand something: in the doc, it writed the engine supports only 8 bits depth channels for the PNG format.

I said, that's a limitation.

But now you say the engine does import PNG textures with 16bit/channel, so I don't get the problem.

Examinant

Answer 6

There is a misunderstanding somewhere from myself, then.

Concretely, should i choose 8 color depth, or 16 colors depth ? The manual said:

Precision is limited to 8 bits per channel upon importing

So that's means i must choose 8, if i choose 16, i will have an error or garbage, like you said, this is correct ?
But it's not the case, godot works well, without visible "bugs" or visual issues. That's why i looking for to understand "why it works with texture as 16 colors depth if it shouldn't ?".

Incogitant

Answer 7

and 24 bits depth.

8 bits per channel * 3(no alpha channel) = 24 bit image buffer.

edit: I see Chunk already pointed this out.

---

What happend if i stay with these values ? I mean, why do i need to respect the 8 channels quantity ?

You dither your textures/channels before you convert from 16 bits per channel down to 8 bits per channel.

Dunstable

Answer 8

I gave you an explanation of how channels and bit depth are related and how to calculate the size of a pixel in bits. With PNG, it can be 8 or 16bit per channel, but 8bit is sufficient for any case of colouring or texturing.

I said if you try to import a 16bit/channel texture where only 8bit are supported, you get an error or garbage (edit. or graceful crash, or the importer takes care and converts to 8bit, which is what I would do in such a case). You didn't state initially you're actually doing it and it works.

Btw., where does it say Godot only supports 8bit/channel PNG textures ?

Is there a reason you're using 16bit/channel ? Unless for specific use cases like monochrome height maps for example this doesn't make sense. Always keep the amount of data small.

Examinant

Answer 9

Thank you, . And that's the answer.

So the importer converts upon import to 8bi/channelt. That answers your question, Gambier .

And it also means that, as far as Godot is concerned, 16bit/channel PNG textures make no sense. If you need the precision, you must choose or write a different importer.

Examinant

Answer 10

Allright, all is clear now, thank you.

Incogitant

Answer 11

Ehh, let me bring out the necronomicon of realtime/vidjagaem graphics:
https://polycount.com/discussion/148303/of-bit-depths-banding-and-normal-maps

Also worth checking out the main page for normalmaps, sheer amount of further linked content mighty be a bit overwhelming tho:
http://wiki.polycount.com/wiki/Normal_map

Dunstable

Answer 12

That's good info. I didn't know that dithering could help so much, and I've definitely seen those normal maps artifacts before in Godot (so I assume they don't do dithering).

Icehouse

Answer 13

and I've definitely seen those normal maps artifacts before in Godot (so I assume they don't do dithering).

I don't think any engine does it on import. This is a authoring/content creation issue for artists to deal with. In a big studio production pipeline an art director would likely tell the artist 'ok, this asset is good enough an passes design stage, hand over to the TD'. TD = technical director, who would then deal with final technical adjustments such as this and exporting to/importing into engine.

Dunstable

Answer 14

Right, makes sense.

Icehouse

Answer 15

When you stick to the recommended 8 bits, you're in the safe lane for most applications. Anything beyond, and you might hit a bump in the road where some systems might struggle to keep up. It's like trying to fit a square peg in a round hole – doable, but not always smoothly.
You could also use a JPEG Optimizer - when you compress image, you're essentially finding a balance between quality and file size. Anyway, it could mean less heavy lifting for your system and faster load times.

Overrate