Color Pallet

Discussion in 'Suggestions' started by Fisch050, Jul 1, 2017.

  1. Fisch050

    Fisch050 Lieutenant

    Joined:
    Jun 10, 2017
    Messages:
    38
    Likes Received:
    32
    A bit is a 0 or a 1, yes. However...
    A byte is 8 bits
    A nibble is 4 bits
    64 bit machines primarily has to do with bus width (I'm simplifying a bit, but close enough). This determines, among other things, total addressable memory. A 32-bit OS running on a 32-bit machine can address 4 GB of memory. A 64 bit OS running on a 64 bit machine can address 16 Exabytes of memory. With overhead, the actual usable RAM is somewhat lower, but the theoretical limits are as stated. In both cases, a byte is still 8 bits.

    In summary, a byte is always 8 bits. It doesn't matter what the underlying bus width of the machine is, a byte is still 8 bits.

    Additional trivia: a lower-case b means bits, and an uppercase B means bytes. So, network speeds of 100 Mbps means 100 mega bits per second. This works out to 100/8=12.5 MBps, or 12.5 mega bytes per second.
     
    #21
    oojimaflip likes this.
  2. Fisch050

    Fisch050 Lieutenant

    Joined:
    Jun 10, 2017
    Messages:
    38
    Likes Received:
    32
    It's the amount of space required to store the information. A 24-bit color space (~16.7 million colors) requires three full bytes to store the data: 00-FF for R, 00-FF for G, 00-FF for B. This works out to 0-255 for Red, 0-255 for Green, and 0-255 for Blue. 1 Byte has 8 bits, which equates to 256 different combinations. 0000 0000 through 1111 1111. A nibble, as mentioned, is 1/2 byte (think a "small bite" and you get the "geek humour" in "nibble"). Since hexadecimal (hex) neatly splits the byte into two nibbles, hex is frequently used to represent the values.

    If you have 32 colors, then you only need 5 bits to store the color information. (2^0=1) + (2^1=2) + (2^2=4) + (2^3=8) + (2^4=16) == 31. The range 0 through 31 gives 32 possible values.

    5 bits is way less space than 24 bits, and thus would take up considerably less space to store and manipulate.
     
    #22
    oojimaflip likes this.
  3. GTv

    GTv Captain

    Joined:
    Feb 28, 2017
    Messages:
    868
    Likes Received:
    605
    This will help you understand.

    https://web.stanford.edu/class/cs101/bits-bytes.html

    File size is not going to suddenly or magically increase because the data is already there now, just a smaller pallet of colors. The file does not know how many possibilities there are, it only stores the ones used.

    The file size is not dependent on the nibble size.
     
    #23
    Last edited: Aug 8, 2017
    TNTBOY479 likes this.
  4. Fisch050

    Fisch050 Lieutenant

    Joined:
    Jun 10, 2017
    Messages:
    38
    Likes Received:
    32
    The link does a good job of reinforcing and expanding on my prior comments (a byte is 8 bits, etc.). Basic computer science stuff. My kids all know that stuff, and they're not in high school yet.

    The application does not store 3 bytes of information for each color. It does not need to. In short, the data are not already there now. As mentioned in an earlier post, indexing makes things easy, and vastly reduces the amount of data required to store. It's also simple, and is used in real-world applications, including the GIF file format.

    At the start of the file (or end, or some other known location), you store the limited color palette. In this case, you store 32 colors. Each color is represented by a bit pattern. With 32 colors, you will need 5 bits to represent all possible patterns. Then, instead of referencing the full 3-byte color, you reference the index/hash/dictionary value of the color. Now, instead of 3 bytes for each color, you are referencing 5 bits, and your storage requirements have vastly shrunk. Even if you have to store 1 byte, your storage requirements have vastly shrunk. On top of that, you can use intelligent organization. These sets of planes are all this color, those are that color, and so on. Then, you store even less information. But you are only storing the index value. With additional compression tricks, you can further reduce the file size.

    This is why I stated, way way back earlier, that we are sort of talking worst-case scenario here - every face of every block is a different color. In reality, that will not be the case, and the file size will not be 6x the size, or 3x the size, or whatever. It will be some percentage less than that, but still more (and typically considerably more) than the current file size. Thus, a custom palette that lets us choose which 32 hex values we can set up for the lookup table/index would not alter the file size, but would permit us to have any 32 colors we want. And, quite frankly, 32 colors should be enough for all but the most (and least o_O) talented designers.
     
    #24
    oojimaflip likes this.
  5. Fisch050

    Fisch050 Lieutenant

    Joined:
    Jun 10, 2017
    Messages:
    38
    Likes Received:
    32
    OK - this changed some from my prior reply. Upon closer reading, we may be stating similar things. Use a palette of colors that is indexed. The palette will never be the full 24-bit RGB color space, so the palette will always be smaller. Store the index value. Apply known, standard compression techniques, and the file size will not increase a meaningful amount.

    Even if a palette of 256 colors were permitted (like GIF), it would not increase the file size much, as the extra 3 bits of information would not amount to a whole lot of extra space, after additional compression techniques were applied.
     
    #25
    oojimaflip and Kieve like this.
  6. GTv

    GTv Captain

    Joined:
    Feb 28, 2017
    Messages:
    868
    Likes Received:
    605
    Yep, and you know what? I wouldn't care if my files for my ship and base were a gb each, most computers have plenty of space for storing files, and I don't upload or download to the workshop anyways. :)
    If I had to I could store my ship on my 128 Tb NAS. :p

    "Give me a few minutes, honey, I am loading in the big ship now..."
     
    #26
  7. Fisch050

    Fisch050 Lieutenant

    Joined:
    Jun 10, 2017
    Messages:
    38
    Likes Received:
    32
    LOL! I want that NAS! :D

    File size is definitely important for transfers, but locally, yeah, it just doesn't matter that much.
     
    #27
  8. oojimaflip

    oojimaflip Captain

    Joined:
    Oct 6, 2016
    Messages:
    684
    Likes Received:
    1,302
    Storing them isnt the issue.
    But it's irrelevant... I'm on the side of the indexed true colour pallete idea, solves most problems.
     
    #28
  9. oojimaflip

    oojimaflip Captain

    Joined:
    Oct 6, 2016
    Messages:
    684
    Likes Received:
    1,302
    Haha
    Hahahahahahaha
    :D
    OMG
    come back when you know what you're talking about!:mad:
     
    #29
  10. Gatt

    Gatt Captain

    Joined:
    Sep 28, 2016
    Messages:
    566
    Likes Received:
    550
    I would be happy if they at least let us store custom textures and colors like Minecraft resource packs. Even if it was client side only and only I saw the colors that would be nice. It's kinda sad that Minecraft can be modded and customized to have better building tools and customization options than this game.
    I like custom color pallet tied to each blueprint option, i can't see people really needing much more than that, 32 colors would be plenty for most builds if they were the colors you wanted.
    Personally i want to be able to change the texture options more than anything. Half of the textures i can't find a good place for on my builds, so they don't get used at all. I don't really need more options just different options
     
    #30
  11. GTv

    GTv Captain

    Joined:
    Feb 28, 2017
    Messages:
    868
    Likes Received:
    605
    Lol
     
    #31
  12. Frigidman

    Frigidman Rear Admiral

    Joined:
    Mar 19, 2016
    Messages:
    4,675
    Likes Received:
    6,602
    The #1 reason I suggest the pallet-per-entity method, is to not get into these bytewars over file sizes ;)
     
    #32
    Gatt, Space Beagle and TNTBOY479 like this.
  13. GTv

    GTv Captain

    Joined:
    Feb 28, 2017
    Messages:
    868
    Likes Received:
    605
    It's not necessary though. File sizes are no problem at all.
    Just give us a full pallet for things besides armor. The file sizes of armor seem to be just fine with the full pallet.
     
    #33
    TNTBOY479 likes this.
  14. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    1,442
    Likes Received:
    1,809
    As some clarification, this is the way that colors are currently stored in blueprints:

    Each block that has at least one colored face has a 32-bit field devoted to it. Each face gets 5 bits (leaving 2 bits leftover that are currently unused), resulting in the 31 colors (and blank) that we currently have.

    I'd suggest that colors get 64 bits (like textures have) instead of 32 bits, which would expand the potential colors to 1024. Alternatively, or even additionally, @Frigidman's custom color pallet idea would also be a great option that would not impact file sizes.
     
    #34
    Gatt, oojimaflip and Space Beagle like this.
  15. Track Driver

    Track Driver Lieutenant

    Joined:
    Jun 27, 2016
    Messages:
    22
    Likes Received:
    28
    I like it! Let's do it!
     
    #35

Share This Page