Hello Everyone, Over on Github there's a great discussion going about how color() should work in the next release. We're trying to write a specification using the language of RFC 2119 <https://datatracker.ietf.org/doc/html/rfc2119> and approaching the end. If you'd like a sneak preview, please read the first comment at https://github.com/openscad/openscad/issues/6309 Usage examples: https://github.com/openscad/openscad/issues/6289#issuecomment-3425784290 If you want to weigh in, please at least skim/search the predecessor issues and read all comments of the current issue, because a number of things have already discussed: 1. https://github.com/openscad/openscad/issues/5966 2. https://github.com/openscad/openscad/issues/6289 Thank you, Cory Cross

On 10/24/2025 10:37 AM, Cory Cross via Discuss wrote: > Hello Everyone, > > Over on Github there's a great discussion going about how color() > should work in the next release. We're trying to write a specification > using the language of RFC 2119 > <https://datatracker.ietf.org/doc/html/rfc2119> and approaching the end. > > If you'd like a sneak preview, please read the first comment at > https://github.com/openscad/openscad/issues/6309 > Usage examples: > https://github.com/openscad/openscad/issues/6289#issuecomment-3425784290 > > If you want to weigh in, please at least skim/search the predecessor > issues and read all comments of the current issue, because a number of > things have already discussed: > > 1. https://github.com/openscad/openscad/issues/5966 > 2. https://github.com/openscad/openscad/issues/6289 > > But I think the capsule summary is: * Color and transparency would be settable independently, so that color("red") color(alpha=0.5) cube(), in either order, would yield a transparent red cube.  In theory this is incompatible, if you were previously creating a transparent object and then forcing it back to opaque by setting its color.  Workaround:  explicitly set the alpha to 1. * Some error cases (supplying fewer than 3 or more than 5 values) might get new warnings. * Behavior in error cases (invalid RGB values, type errors, et cetera) might change.

On 10/24/25 13:37, Cory Cross via Discuss wrote: > Hello Everyone, > > Over on Github there's a great discussion going about how color() > should work in the next release. We're trying to write a specification > using the language of RFC 2119 > <https://datatracker.ietf.org/doc/html/rfc2119> and approaching the end. > > If you'd like a sneak preview, please read the first comment at > https://github.com/openscad/openscad/issues/6309 > Usage examples: > https://github.com/openscad/openscad/issues/6289#issuecomment-3425784290 > > If you want to weigh in, please at least skim/search the predecessor > issues and read all comments of the current issue, because a number of > things have already discussed: > > 1. https://github.com/openscad/openscad/issues/5966 As a broadcast engineer since 1962, this seems to equate, using different words I am not familiar with, language evolution related I suspect given the English speakers propensity to invent new words when the current model is deemed insufficient to convey the meaning, to something that seems to resemble NTSC.  There, when colorimetry experts were working on it, the alpha channel was translated by summing the RGB values and became the monochrome or brightness signal. But based on the perceived brightness, the summing network was adjusted so that the perceived brightness of each color corresponded to how the average person with good color vision saw its brightness.  So solid blue contributed only 11% of the brightness weight in the summed monochrome signal. And I'll confess to having forgotten the % of the red & green from the cameras. The crt displays at the time all used additive colors but the phosphors used in the screens had wildly different efficiencies so it took the tv makers several years to develop better phosphors & they are still playing with it. Color printers OTOH, are stuck by generally white paper, and use inks of complementary colors some makers haven't fully grokked yet altho Epson and Brother seemed to have that optimized pretty good. complementary colors there are magenta(reflecting red+blue & absorbing green) yellow(reflecting red+green & absorbing blue) and cyan(reflecting green+blue & absorbing red). It took the printer makers nearly 40 years to get those inks somewhere near right. And none are archival quality yet.  Light fades them, each color at a different rate. Not our problem. Even the Mona Lisa is kept in the dark when there is no one in the room. What I'm trying to say is that doing it NTSC style allows us to use a well developed std we used in broadcasting from 1962 to 2008 when we went digital.  Much of that math has already been done and prolifically documented. Its public domain stuffs.  Digital is basically an 8 level signal, giving an rrddbbaa but encoded such that the average power output measured by calories of heat it generates in a dummy load, is held at a 50% average value. NTSC didn't do that with a black pix using a lot more power than a white pix. > 2. https://github.com/openscad/openscad/issues/6289 > > > Thank you, > Cory Cross > Just an old engineers 2 cents. > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Don't poison our oceans, interdict drugs at the src.