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 ?

  • Pixophir, Megalomaniak, and Tomcat replied to this.
  • Pixophir 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.

    TwistedMind 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.

    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.

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

    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.

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

    TwistedMind '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.

    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 ?".

    TwistedMind and 24 bits depth.

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

    edit: I see @cybereality already pointed this out.


    TwistedMind 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.

    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.

      Pixophir 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.

      TwistedMind 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.

        Thank you, Tomcat . And that's the answer.

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

        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.

        Allright, all is clear now, thank you.

        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).

          cybereality 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.

          a year later

          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.