Colors in the product data network

[christoph-maurer]

Currently, the product data network uses the CIELAB color space (example, schema) and IGSDB uses the [CIEXYZ color space]. There are calculations available to convert colors from CIELAB to CIEXYZ and reverse.

@RDmitchell @danielmcquillen If Fraunhofer changes from CIELAB to CIEXYZ, would it be easy for you to offer X, Y and Z in the same way as you already offer nearnormalHemisphericalVisibleTransmittances?

[danielmcquillen]

@christoph-maurer @RDmitchell

In IGSDBv2, the UI for the product detail page provides Tf, Rf and Rb color information in three formats:

For example, the coated product at https://igsdb-v2.herokuapp.com/products/low-e-6/

[danielmcquillen]

The json structure provided by the api provides a scaffolding for more information about color. However, at the moment most products (which have been directly imported from the IGDB) only have a few fields with actual values.

This information is located in the dictionaries within the integrated_spectral_averages_summaries list (there's usually only one dictionary, representing the summary values for the NFRC standard.

This dictionary includes the color key, which contains lab, 'rgb', and trichromatic data for each combination of reflectance front/back and direct/diffuse combinations:

For example:

https://igsdb-v2.herokuapp.com/api/v2/products/clr-3/

[christoph-maurer]

@danielmcquillen I like how you attach color to the integrated_spectral_averages!

When I move "color" to the "results", would it be easy for you to include it into BED-JSON data sets? Would it also be easy to return the CIE L*a*b* values in GraphQL?

[danielmcquillen]

@christoph-maurer Sure, I can look into that this week. It's probably easier to update the BED-JSON output so I'll look at that first.

[danielmcquillen]

@christoph-maurer Can you provide an example product json in BED-JSON format that demostrates where the color values (generated as part of the integrated summary values generation) would go?

[christoph-maurer]

@danielmcquillen Yes, I'll work on it. I will send it to you as soon as it is ready.

[danielmcquillen]

@christoph-maurer Awesome. I'll work with @RDmitchell and Jacob to update once you've got some guidance ready! (By the way, would it make sense to add Jacob to your repo so he can comment? https://github.com/jcjonsson ... Robin is out of the office for a couple weeks.)

[christoph-maurer]

@danielmcquillen Excellent idea! I have added @jcjonsson and @RDmitchell to the team EQWIN- P_associated_partners. This should give them access to all relevant repositories.

[christoph-maurer]

@danielmcquillen I have moved the keys for color in the schema opticalData.json to "results". I have created a test as example for color data based on https://igsdb-v2.herokuapp.com/api/v2/products/clr-3/ . The API specification for databases was already including fields for color.

It is nice when the product data network can be queried for color. But it has a low priority, because it is not currently needed by a project partner.

[danielmcquillen]

@christoph-maurer Thanks for making a "test" to illustrate how the data is shaped in an example.

I'm confused though as the "test" example you provided seems to indicate color information available at every wavelength, yet in the IGSDB color is only available at a higher level: once for each standard used to create integrated spectral average summary values (at the moment, we only do this for one standard, the "NFRC" standard, but there's capacity to support others).

In other words, we don't have color information at every wavelength.

Here's a snippet of clr-3 through the current IGSDB v2 API in bed-json format showing the measured data at 300nm:

Given that color data is part of integrated summary values, and at a higher level than measured data, I would have thought any color information would appear as a property of componentCharacteristics or another higher-level key, not further down into the actual dataPoints list.

Yet in your example it would appear this color information appears at every wavelength (although I could be misunderstanding!):

If you do need color data at this granularity, could it be you need a new node to describe a more global color determined by integrated spectral averages summaries (which Checkertool generates using pywincalc).

Furthermore, I noticed in your test example you have this:

Yet in the current IGSDBv2 implementation of the "bed-format" for the REST api, each data point has a wavelengths dictionary, and that dictionary has a single wavelength field with the actual wavelength for that datapoint in nm as a value. Such as :

"wavelengths": {
   "wavelength": 300
}

I also find it interesting that "dataPoints" holds a list of dictionaries where there is one "dataPoint" dictionary for each wavelength of data. Yet, within that dictionary there is a "wavelengths" key with another dictionary holding a "wavelength" key....if each dataPoint dictionary contains a single wavelength, why is there a need for "wavelengths"? Isn't that superfluous? Asked another way, when will that internal wavelengths dictionary ever hold data for more than one wavelength when the parent dataPoint describes one wavelength, such as 300 in the example above.

Is there something amiss here or is this all ok?

(@jcjonsson FYI in case you have comments...)

[christoph-maurer]

Hi @danielmcquillen , https://igsdb-v2.herokuapp.com/api/v2/products/clr-3/?format=bed-json currently contains dataPoints for single wavelengths like

        {
          "incidence": {
            "wavelengths": {
              "wavelength": 300
            },
            "direction": {
              "polar": 8
            }
          },
          "emergence": {
            "direction": {
              "polar": 8
            }
          },
          "results": {
            "transmittance": "0.0",
            "reflectance": "0.0467"
          }
        },

as well as dataPoints integrated over a spectrum like

        {
          "incidence": {
            "wavelengths": {
              "integral": "visible"
            },
            "direction": {
              "polar": 8
            }
          },
          "emergence": {
            "direction": "hemispherical"
          },
          "results": {
            "transmittance": 0.9044294,
            "reflectance": 0.08225197
          }
        },

wavelengths can either have the key wavelength to define a single wavelength or the key integral to define a spectrum over which the results are integrated.

My proposal is that you extend integrals over the visible spectrum with the color data. For example, you can change the last example to:

        {
          "incidence": {
            "wavelengths": {
              "integral": "visible"
            },
            "direction": {
              "polar": 8
            }
          },
          "emergence": {
            "direction": "hemispherical"
          },
          "results": {
            "transmittance": 0.9044294,
            "colorTransmittance": {
              "cielabColors": [
                {
                  "aStar": -0.8035122491914515,
                  "bStar": 0.2168086516082468,
                  "lStar": 96.18335944095739
                }
              ]
            },
            "reflectance": 0.08225287,
            "colorReflectance": {
              "cielabColors": [
                {
                  "aStar": -0.4781490764729779,
                  "bStar": -0.4878317966566348,
                  "lStar": 34.46499873850816
                }
              ]
            }
          }
        }

The schema opticalData.json allows the keys colorTransmittance and colorReflectance only if

            "wavelengths": {
              "integral": "visible"
            },

It is therefore not possible to define the color for a single wavelength or for another spectrum than visible.

@danielmcquillen Does this help to clarify the issue?

[danielmcquillen]

Thanks for the clarification, Christophe. Very helpful. Traveling this week but will update the serializer as soon as I return next week.

On Mon, Jul 15, 2024 at 8:02 PM, Christoph Maurer @.***(mailto:On Mon, Jul 15, 2024 at 8:02 PM, Christoph Maurer < wrote:

Hi @.***(https://github.com/danielmcquillen) , https://igsdb-v2.herokuapp.com/api/v2/products/clr-3/?format=bed-json currently contains dataPoints for single wavelengths like

{ "incidence": { "wavelengths": { "wavelength": 300 }, "direction": { "polar": 8 } }, "emergence": { "direction": { "polar": 8 } }, "results": { "transmittance": "0.0", "reflectance": "0.0467" } },

as well as dataPoints integrated over a spectrum like

{ "incidence": { "wavelengths": { "integral": "visible" }, "direction": { "polar": 8 } }, "emergence": { "direction": "hemispherical" }, "results": { "transmittance": 0.9044294, "reflectance": 0.08225197 } },

wavelengths can either have the key wavelength to define a single wavelength or the key integral to define a spectrum over which the results are integrated.

My proposal is that you extend integrals over the visible spectrum with the color data. For example, you can change the last example to:

{ "incidence": { "wavelengths": { "integral": "visible" }, "direction": { "polar": 8 } }, "emergence": { "direction": "hemispherical" }, "results": { "transmittance": 0.9044294, "colorTransmittance": { "cielabColors": [ { "aStar": -0.8035122491914515, "bStar": 0.2168086516082468, "lStar": 96.18335944095739 } ] }, "reflectance": 0.08225287, "colorReflectance": { "cielabColors": [ { "aStar": -0.4781490764729779, "bStar": -0.4878317966566348, "lStar": 34.46499873850816 } ] } } }

The schema opticalData.json allows the keys colorTransmittance and colorReflectance only if

"wavelengths": { "integral": "visible" },

It is therefore not possible to define the color for a single wavelength or for another spectrum than visible.

@.***(https://github.com/danielmcquillen) Does this help to clarify the issue?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[christoph-maurer]

Thank you, @danielmcquillen !