Extended Color Hex Format #48
Comments
|
This is a good point. Representing rainbow, dial-color, and tri-color
isn’t something this does yet. We’ll also probably want to plan ahead for
something that hasn’t been invented yet. I’ll give this some thought. If
you’re on the discord server, this might be a good thing to bring up to get
opinions from everyone else.
…On Sun, Nov 24, 2024 at 5:06 AM Willow Herron ***@***.***> wrote:
This is a simple proposal to extend the color hex field in the open source
RFID standard. I have four proposals for how this could be done, in
increasing order of complexity.
A basic implementation would keep a single color, but use 4 bytes in order
to include an alpha channel. As both translucent filaments and RGBA values
are fairly common, this would be a simple change that could support more
filaments while adding only a single additional byte to the format.
Alpha could also be used in non-standard ways to represent things like
twinkling filaments, by dividing its byte in half or more, or using a
lookup table (though this was to be avoided generally, it does provide
unique benefits). Filament translucency should never be more granular than
a single hexadecimal digit, so using 4 bits to represent transparency and
another four to represent other properties would be a simple solution that
reduces size while maintaining the ability to display things like sparkle.
To avoid a lookup table, this could also represent different boolean
properties with each of the bits. For example, four bits could be allocated
to alpha, while the other four represent matte vs gloss, twinkle vs
standard, metallic, and color shift vs monochrome.
Color shift brings me to the next proposal. Many filaments contain more
than one color, and a single hex code is unable to represent their color
adequately. To accommodate this, the bits initially allocated to alpha or
properties could be used to store a color quantity. For example, in what
was initially proposed to be the “alpha” channel, the first four bits could
be allocated to an index and the other four for a quantity. If that number
was three, eg the color hex code was XX XX XX 02, this would be followed by
two more color hex codes. For example, a red-green-blue color shift
filament would be represented by FF00000200FF00120000FF22, or (FF 00 00 02)
(00 FF 00 12) (00 00 FF 22). This provides basic support for color shift
filament, but sacrifices support for visual properties.
The final proposal, though the most expensive, sacrifices nothing. This
would be to use the first byte to encode quantity, with the first half of
the byte encoding channels per color and the second half encoding colors.
for example, 20 XX XX XX would be equivalent to the current situation, with
three bytes per color and a single color, while only taking up one extra
byte, equivalent to the alpha channel proposal. However, this is extensible
up to FF…, which would permit 16 colors with 16 bytes each, for a huge
number of visual properties per color and a huge range of color shift per
filament. A 50% alpha version of the RGB color shift filament described
above, for example, could be represented by 32FF00007000FF00700000FF70, or
32 (FF 00 00 70) (00 FF 00 70) (00 00 FF 70).
The dynamic size of the final two proposals could present problems, but
given the size is presented in a fixed location, it would still be
heuristically parsable. It could also be the final parameter (given it’s
already the second-to-last), which would simplify things.
—
Reply to this email directly, view it on GitHub
<#48>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALFZ7YNI2IUNCPMKQ5D2DT2CGQMDAVCNFSM6AAAAABSMB2UQ6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGY4DONBYHA2TENI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I am not on the discord. I see that it's only been referenced in other issues, and the invite in another issue is broken. Perhaps a perpetual invite in the readme would be good? Either way, an invite to me would be appreciated |
|
An invite has been added to the readme. I wasn't sure if that was something that the original discord owner was ok with, so I had to check first. |
|
The link in the read me actually got removed on accident, here's the link in the meantime: https://discord.gg/zVfCVubwr7 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a simple proposal to extend the color hex field in the open source RFID standard. I have four proposals for how this could be done, in increasing order of complexity.
A basic implementation would keep a single color, but use 4 bytes in order to include an alpha channel. As both translucent filaments and RGBA values are fairly common, this would be a simple change that could support more filaments while adding only a single additional byte to the format.
Alpha could also be used in non-standard ways to represent things like twinkling filaments, by dividing its byte in half or more, or using a lookup table (though this was to be avoided generally, it does provide unique benefits). Filament translucency should never be more granular than a single hexadecimal digit, so using 4 bits to represent transparency and another four to represent other properties would be a simple solution that reduces size while maintaining the ability to display things like sparkle. To avoid a lookup table, this could also represent different boolean properties with each of the bits. For example, four bits could be allocated to alpha, while the other four represent matte vs gloss, twinkle vs standard, metallic, and color shift vs monochrome.
Color shift brings me to the next proposal. Many filaments contain more than one color, and a single hex code is unable to represent their color adequately. To accommodate this, the bits initially allocated to alpha or properties could be used to store a color quantity. For example, in what was initially proposed to be the “alpha” channel, the first four bits could be allocated to an index and the other four for a quantity. If that number was three, eg the color hex code was XX XX XX 02, this would be followed by two more color hex codes. For example, a red-green-blue color shift filament would be represented by FF00000200FF00120000FF22, or (FF 00 00 02) (00 FF 00 12) (00 00 FF 22). This provides basic support for color shift filament, but sacrifices support for visual properties.
The final proposal, though the most expensive, sacrifices nothing. This would be to use the first byte to encode quantity, with the first half of the byte encoding channels per color and the second half encoding colors. for example, 20 XX XX XX would be equivalent to the current situation, with three bytes per color and a single color, while only taking up one extra byte, equivalent to the alpha channel proposal. However, this is extensible up to FF…, which would permit 16 colors with 16 bytes each, for a huge number of visual properties per color and a huge range of color shift per filament. A 50% alpha version of the RGB color shift filament described above, for example, could be represented by 32FF00007F00FF007F0000FF7F, or 32 (FF 00 00 7F) (00 FF 00 7F) (00 00 FF 7F). This proposal could even reduce size for greyscale filaments, by cutting the three byte color code down to two. A mid-grey filament could be represented by 007F. Suggestions for some of these 16 channels are: how long does it take to shift between colors (in mm or other units)? The same boolean properties suggested above, but perhaps more granular (how "twinkly" is the filament?). What portion of the filament does each color occupy (eg, a dual-extruded filament could have a zero for shift distance but AF for one color's portion and 3F for the other if the first color occupies 3/4 of the width of the filament).
The dynamic size of the final two proposals could present problems, but given the size is presented in a fixed location, it would still be heuristically parsable. It could also be the final parameter (given it’s already the second-to-last), which would simplify things.
The text was updated successfully, but these errors were encountered: