[BFW-8115] 'color name' is really missing

[yanshay]

There is no textual field to describe the color color_name, or at least I can't find it.

It's probably the most important field after material_type, since people are not reading hex codes, from the color it's not always possible to tell the color from viewing it on a monitor (e.g. gold) especially if people are color blind.
It's required in every table showing properties of a spool.
It's potentially included in the material_name but could be together with additional information like material type e.g. in your example PLA Lipstick Red - the PLA has separate fields (two - both enum and the name string) but the Lipstick Red doesn't have the name alone, and there is no way to know how to extract it as the material_name is vendor dependent.

It's a major issue for me to integrate OpenPrintTag into my product.

[mytechguyri]

Yes... Good Lord...Black and Galaxy Black will both have a black hex code, but are very different colors. Color name is critical.

[CZDanol]

Hello,
the material_name field is indeed intended and defined to contain both the color and the material information. Having it contain just Lipstick Red without the PLA would actually be against the spec.

Yes... Good Lord...Black and Galaxy Black will both have a black hex code, but are very different colors. Color name is critical.
Following this logic:

1. Are PLA Jet Black and PETG Jet Black of the same color? The color name is Jet Black in both cases, right?
2. Is Black PLA from one manufacturer the same color as Black PLA from another?

My points are:

1. The only case when you can reasonably expect the color of two filaments to be same, is if the filaments are from the same brand and of the same material type. At that point, the identifying name for the color is indeed the combination of Brand + PLA Lipstick Red.
2. You can have two different manufacturers that do make same looking material, but they call the color different names (for example our Prusament PLA Jet Black vs say Filament PM Black). So the color name is really not an identifier of any sense.
3. Brand is in a separate field, because it does have its clear practical uses, and the separation of what is the brand name is clear. But filament namings are actually not that clear.

And some counter-examples:

1. Let's take "Prusament PLA Recycled". By the current standard, you can easily say that "PLA Recycled" is the material name. But if we were to separate material type and color, how would you do that? Is "Recycled" a color? How would you work with that. Or PLA Glow in the dark.
2. How about "PLA Silk Rose"? Is it "PLA Silk" material and "Rose" color name, or is it "PLA" material and "Silk Rose" color name?
3. Or "rPLA Corn Pigment". One could argue that the fact that the material is "rPLA" also affects this color. Note: if you would argue that "rPLA" should be a material type, then "PLA Silk" should also be a material type, right?

So, we've given this a fair share of thought, this was our reasoning why we've decided to not separate these two fields. But feel free to continue this discussion, if we hear good counterarguments, we will reconsider our stance :)

For color definition and matching, we'd rather consider using things like CIELAB or RAL that are being discussed in #62, once we settle down on a good common ground of how things should be defined.

[yanshay]

Very sorry in advance for the long post, it's just pretty important to me (which is a good thing 😄 )

From a theoretical standpoint, you’re absolutely right — the only thing that uniquely identifies a spool’s color is the combination of color name, filament type, and brand, since different brands may use the same color name for different shades.

That said, the same argument could be made about color codes — for example, Gold, Brass, and Copper. Their hex codes alone doesn’t precisely represent the real color, not even an approximation. Only in combination with Brand and Material type. There is no way to represent those in RGB codes. Would that mean we should exclude them as well because alone they’re not strictly unique representative either? The same code could be used by two brands for filaments that look completely different, because the properties of those are not representable by rgb codes.

But the real issue at hand is the ability to turn this from a formal specification to something usable in products.

As background - I'm developing a product, currently for Bambulab printers which my guess is the most suitable for using this standard (called SpoolEase - https://github.com/yanshay/SpoolEase). It includes inventory management, AMS slot configuration, dual method weight tracking and more. Everything evolves around NFC.

I estimate a few hundreds of Bambulab users are using it and are pretty happy with it. I believe it's the only actively developed product in this space covering so many aspects, at least for Bambulab printers.

One of the things users want is just to find a color, let's say 'Black' or 'Gold' or 'Copper' when they have in their inventory the same color from multiple brands. And probably 99% of the times they don't really care of it is Sunlu black or eSun black even though they are very different. They are way more interested in how much is left in the spool to optimize usage. Therefore, I have a Color solumn. And it is probably not unique to my product.
So I allow them to filter the color field. Without such field, I have a problem integrating this into my product without a pretty large refactoring or with extra work on the user's behalf (which is probably what I'll go for if I do the integration). I also don't have a field for a complete spool name, so that's even more refactoring if I do want to add it.

Another use case - the product includes a 3.5" display with very limited space. So in some cases I display brand separately from color, in some cases only color is interesting (as you'll see later brand is one of the least interesting data points, actually added late in the product's life just for completeness). If the only way to get to color name is by displaying brand name and type and color - it would break everything. So user would need to tweak the data after importing it from the spool

If this standard had existed a year ago, maybe I'd do it differently. But when you introduce a standard to an existing world, it should fit existing implementations unless something doesn't make sense, which I don't think is the case here.

To some of your questions:

Are PLA Jet Black and PETG Jet Black of the same color? The color name is Jet Black in both cases, right?

For some use cases no, but for most use cases definitely big yes. When I want to print something in black, I search Black, SpoolEase shows me what I have and which spool is curretnly in my AMS, I don't mind and I print with it. If I had Black PLA I would use it. When I need something that's heat resistant I would make the extra effort to replace the spool.

Is Black PLA from one manufacturer the same color as Black PLA from another?
For most of the use cases absolutely yes. I have blacks from many brands, going for the cheapest option. I guess most users do that, especially with Black, White and Gray, and also with other colors (Red, Green, Yellow, etc). Unless they do HueForge and then even color data is not accurate enough for them. When I want to print something black, I really don't know that Sunlu black is different from eSun, and in what way. I almost always never care (and I say almost without any case I ever cared).
And the fact I know it is eSun yellow or Sunlu yello, doesn't help a bit, in such case I need to look at the spool to tell. The fact there's brand next to it doesn't help me in anyway, and I see it anyway from another column in the table (that you have in the spec).

Let's take "Prusament PLA Recycled". By the current standard, you can easily say that "PLA Recycled" is the material name. But if we were to separate material type and color, how would you do that? Is "Recycled" a color? How would you work with that. Or PLA Glow in the dark.

Glow in the dark - You could ask the same - what's the hex code of that color? when it is tested in the dark? or when it is tested during daylight? it's not well defined so is should not be included as rgb?
Recycled - don't know what it means, but doesn't sound like color name, just like high speed is not color name. However, if the brand used the term 'recycled' to reflect it is related to some color known as recycled, it should be in the color name. If it is to state that it is 'Green' material made from recycled ingridiants, then it is not the color. The manufacturer should decide about that. It's not like computer code will do any math with that field which could cause issues - it is only for user facing applications.

For color definition and matching, we'd rather consider using things like CIELAB or RAL that are being discussed in #62, once we settle down on a good common ground of how things should be defined.

I'm not that familiar with these standards but AFAIK CIELAB is not user facing. It's a set of numbers eventually. I want to print a vase in yellow, and search for a suitable spool, will I search for the code by RAL and CIELAB.
If RAL includes color names, I'm good. I don't mind where the names come from, if these are stanard or manufacturer defined. As long as it is text that means something to a user I'm good. It is important for me though, that the text will be included in the tag itself, and I won't have to include a huge list of strings in my embedded device since these embedded devices are low on memory and many times would be the consumers of these tags.

Note that color name is included in: https://opentag3d.info/spec .

Sorry for the long post, almost an article, it's just a pretty critical field IMO, not some nuance to the spec.

Here is a screen shot of part of the product to give you some more color on how this field is to be used:

[mytechguyri]

I disagree... For example, I can buy "burnt titanium" PLA, "burnt titanium" PETG, and burnt titanium ASA.. I can buy some of those those from FlashForge, Voxelab, and Filabees... IMHO there's no distinguishable difference in shade between the three (since at least two of those, possibly all three, are actually the same manufacturer, just different sub brands)... Yes there would be differences with material, but your printer generally only cares what type of material you have... I.e. ASA black, and ASA orange from the same manufacturer will print pretty much with identical settings..(yes, I know settings CAN vary between colors, and color can impact how a material prints, but honestly, the average user simply isn't getting that granular). Plus the average user simply is not getting into the minutia of subtle shade variations the color_name field isn't so much for machine use, but for human use... If I'm importing the tag into an inventory management system, I likely don't care if it's black #020202 or black #000000 I just care "how much black PLA do I have on hand?". Matter of fact, I currently code all my black filament as #000000... Because ive never had a case where I've had to know, "how much #020202 PLA do I have on hand?"

Further, particularly with cheaper value brands, you get subtle shade variations simply because of less strict quality control, and variation between batches, so the 3DHojor orange PLA I bought last month will be a different shade from the 3DHojor orange PLA I buy today...

Then you've got unique variations that RGB codes cannot even begin to accurately represent ..for example, what about dual and tri-extrusion colors.. red green blue tri-extrusion....do I code lt with the red hex code, the green hex code, or the blue hex code? But a color_name of "Red Green Blue" well now I can clearly see this is a tri-extrusion filament with red, green, and blue.

I honestly think NOT having a color_name field is a deal breaker for me that would halt me even considering adopting this as a "standard", rendering the Prusa spool tags as a useless feature that doesn't bring any usable value add at that point, because it lacks the real world information that I need to utilize it most efficiently.

[garrickp]

I want to support @yanshay's argument, and I do have a couple more counter examples from Prusament's own store: What hex code would - could - be assigned to Prusament Algae? How would the Prusament wood fill filament be categorized?

There's also cases where there is no color assigned, such as undyed batches of filament.

Anyways, thank you for the discussion!

[yanshay]

Another data point from SimplyPrint filament database:

    "properties": {
        "color_name": {
            "type": "string",
            "description": "The manufacturer's name for this filament color",
            "$ref": "#/definitions/string_limit"
        },
.
.
.
    "required": [
        "color_name",
        "color_hex"
    ]

It's a required field in their case as well for probably similar reasons.

[CZDanol]

In this comment I will be reacting only to some specific things, not necessarily main topic of this thread - that I will think about more and discuss it with colleagues, before making stances. So please consider it as that.

Their hex codes alone doesn’t precisely represent the real color, not even an approximation. Only in combination with Brand and Material type. There is no way to represent those in RGB codes.

I completely agree with you. The hex codes are intended for UI purposes mostly.

Would that mean we should exclude them as well because alone they’re not strictly unique representative either?

No, because they have their purpose - displaying a color in the UI. You don't need to be quantify whether two colors are the same or differ, you just need something to show to the user.

Glow in the dark - You could ask the same - what's the hex code of that color? when it is tested in the dark? or when it is tested during daylight? it's not well defined so is should not be included as rgb?

We have a concept of a primary color and secondary colors, as you can see in the spec. In the case of glow in the dark, I would recommend setting the "standard" daylight color as the primary color, and the glow color as the secondary.

In some cases, not setting the RGB value is also a valid option, for example for rainbow filaments (although there you can also list some key gradient colors in the secondary color list.)

However, if the brand used the term 'recycled' to reflect it is related to some color known as recycled, it should be in the color name.

And this ambiguity is a big problem, when you're trying to make a standard. If "Recycled" should be in the color here, you could argue that in rPLA Corn Pigment, the "rPLA" should also be in the color name. And voila, you've ended up with out material_name. If you don't do that, there would need to be clear and consistent guidelines.

If RAL includes color names, I'm good.

It's more complicated with RAL. It's a swatch system, meaning it only contains discrete samples from the color space. It's not intended to describe "any color", it's intended to provide a clear reference for a set of specific colors.

f I'm importing the tag into an inventory management system, I likely don't care if it's black #020202 or black #000000 I just care "how much black PLA do I have on hand?". Matter of fact, I currently code all my black filament as #000000

Well, this applies for your local management system. But when you don't control the dataset yourself manually, you will be getting tags from manufacturers with these various hex codes. And those manufacturers will also not necessarily put "black" in the color name, but for example "midnight gray" or "anthracite", so looking up by the color name string won't help either.

The best course here to find approximate matches would be to do a range-based (so not exact match) lookup by RGB, or by some other color system.

Then you've got unique variations that RGB codes cannot even begin to accurately represent ..for example, what about dual and tri-extrusion colors.. red green blue tri-extrusion....do I code lt with the red hex code, the green hex code, or the blue hex code?

This is covered by the spec. In case of coextruded filaments, you would leave the primary_color null, and put the red, green and blue as secondary_colors. You would also add the coextruded tag.

But a color_name of "Red Green Blue"

But that's not what a manufacturer will necessarily put there. The manufacturer can name the product "Metalic Frenzy" and leave it at that:

[yanshay]

Thank you for taking the time and considering this.

I will only restate what you wrote:

Their hex codes alone doesn’t precisely represent the real color, not even an approximation. Only in combination with Brand and Material type. There is no way to represent those in RGB codes.

I completely agree with you. The hex codes are intended for UI purposes mostly.

Would that mean we should exclude them as well because alone they’re not strictly unique representative either?

No, because they have their purpose - displaying a color in the UI. You don't need to be quantify whether two colors are the same or differ, you just need something to show to the user.

color_name serves the exact same purpse as the hex code. It's just the textual form. Not for comparison or any algorithmic function.
You could even call it ui_color_name to make sure it's clearly understoon, or manufacturer_color_name.
color_name at the end of the day is required for UI for consumption by end users.

An interesting example, one of the users of my product print swatches for all his filaments, but adds a small label with the color name since his child is color blind and all swatches look to him more or less the same, but still does colored prints. Hex code is not something easily read by users, especially not young and not technical who still print. Among themselves they communicate with the color name on the swatch.

I also had second thoughts about RAL as a replacement to this, and I believe it's not a good replacement. Technically it will solve my issues but for users it won't. RAL if I get it right is for formal colors but manufacturers use many times crazy names like "Royal Essence" above. That's why the user buys, that's how they recognize their filaments, thats how they communicate about that filaments (even at home, father and child). I remember another user telling me something about his 'Truck Red' spool.

So indeed it's all a matter of UI which in many situations, need separately to access the brand, material (I'd say also sub-type of material) and color_name.

The material_subtype (also for UI, like High Speed, etc.) is also something I'd suggest you look at, again, it is a manufacturer subjective name, but it is not nearly as important as color_name which is absolutely critical IMO.

Thanks again for taking the time to respond and consider this.

I'd appreciate if you can update here on the decision so I know if I can go ahead with integrtion into the product.

[darraghbr]

Because the material type is encoded as an integer it might work to have 'Material Name' as just the materials colour name or attribute, then for display purposes just concatenate the 'Brand', 'Material Type' and 'Material Name' fields together. Currently you have the material type stored seperately in two places where ideally it should just be one.

For the example of Recycled material, the 'Colour Name' (unless additional pigment is added) would be 'Natural', but clearly, calling the 'Colour Name' of rPLA Corn Pigment 'Corn' doesn't really make sense, it's more of an attribute than a colour, same with glow in the dark materials.

You could also break it out completely and have seperate material type, colour name and display name fields, although there is a lot of duplication. For me, concatenating the fields in a specific (customisable?) order to come up with the 'display name' for a material makes the most sense.

As a sidenote, as much as I think the concept of 'high speed' filaments is nonsensical, having it as a material tag would be required by a number of filament manufacturers.

[yanshay]

I agree that only separate part fields is better than only concatenated string, but not sure manufacturers would like that since they will want to be able to express their marketing name.

Let's take some example, imaginary, but realistic:

Polymaker PolyLite Conductive High Speed PLA Dark Creamy White Marble.

Manufacturer/Brand: Polymaker
Product line: PolyLite
Material Type: PLA
Subtype: Condictive High Speed
Color Name: Dark Creamy White Marble.

In my product I implemented these separately (just missed the product line and it does cause me issues in some cases to actually make things work, not just display, but selecting technical things under the hood like slicer setting, so I deal with it as a special case and know to identify that PolyLite is from Polymaker, etc.).

The keys points that I think are key to understand when it comes to such standard:

1. It arrives very late - so it needs to map the existing world and not shape the world. Because it won't force everyone to do things correctly. Errors if there are out there needs to be accomodated.
2. The standard needs to serve products. If it is theoretically correct but will cause issues to products that need to use it, it will simply not get adopted, or at least not as wide and not as fast.

[CZDanol]

Just a heads up, I am not letting this die. We've been having internal discussions. I do see your points and I'm trying to find ways around it.

A big issue now is backwards compatibility.

1. There is already the material_name field and there are already spools being produced with this data, and we are already populating a filament database with this data format.
   1. If we were to just add color_name, there would already be spools with this field missing, so the datapoint would already be unreliable.
   2. Additionally to that, "just adding" the color_name would mean that on a "proper" tag, the color name would have to be written twice, in both material_name and color_name. That would cost space on a not-so big tag.
   3. To address that, we would also need to add something like material_type_name to "fit" the for example "PLA High-Speed" part, so that the material_name could be "split" into two fields and wouldn't have to be present itself.
   4. As a result, the standard would get less standard, and the integrators couldn't properly rely on either of these fields, because some manufacturers would choose to use material_name and some the type + color combo.
2. To fullfill the OpenPrintTag role as a standard, we would need to come up with guidelines of what is part of the color name ("PLA Silk" + "Red" vs "PLA" + "Silk Red") and what is part of the material type - extra work for us and for anyone who prepares the data.

An interesting example, one of the users of my product print swatches for all his filaments, but adds a small label with the color name since his child is color blind and all swatches look to him more or less the same, but still does colored prints.

I don't see why there couldn't be the material type on the label as well. In fact, I would find that beneficial.

[yanshay]

I think making the standard and crippled for use by real products for backwards compatibility at such early stage of it would be a a huge miss. Not just with this but in general.

You should support standard versioning, that's pretty standard in standards and at most first batches would not include it while later will. If it's long term project that wouldn't be an issue.
Much larger scale standards, development language break backwards compatibility and surely at early stages to be long term sustainable.

As for your question on why not include material - the field currently available could easily reach 8 or 10 words. Small readable labels can't handle that just like table columns can't. I think the standard lacking breaking properly as vendors decide to brand, product line, material, subtype and color name will prevent supporting it.
I am really stuck with that right now, don't see how I can add it to a real product. You can check it out and see why.

[yanshay]

BTW - as another data point.
Bambu Lab also didn't think about it a few years ago with their tags and color name is not included while they have rgba and also support multicolor filaments, material type and other fields.

But... THEY needed it for Bambu Studio and Handy and maybe elsewhere, so they now maintain in Bambu Studio a json file to derive from material and rgba the color name and use it in their own software because it is required and requested by users.

I used it to support Bambu Lab tags. It's doable with a single or a couple of dominant brands but not when the target is tens of brands.