Yeah..i was working on that yesterday. I’ll clear this one up.
It’s something about this posters data. There’s an extra set of nm values after the max wavelength. I’m going to add a way to filter that automatically. It’s on all of his reports.
1 Thank
That’s fixed now too..it also scrubs the data as it comes in
Amazing, I can confirm that the extraneous curves have been fixed! Scrubbing everything but the raw intensity-per-wavelength numbers is a good move.
1 Thank
outstanding database you are building, thank you!
I hope more reports will include the Lumen Level for posted DUV, since Output affects DUV.. for example these two reports leave me wishing there was an Output referenced:
also, Im wondering what devices are being used to obtain the data?
thank you for the tremendous effort you are putting into developing this resource
1 Thank
Currently Hopoocolor, Torch Bearer, and Color Munki photo are supported as well as raw wavelength data pairs. There are no plans to incorporate any kind of Opple support.
As for output, I can probably add a field but for now that can go in the title or the notes.
2 Thanks
This would be nice, but also difficult if the user does not have a reliable way to measure total output. Furthermore, output alone might not be sufficient information–the same emitter at the same output can produce different spectra depending on other factors like choice of secondary optic and driver architecture (constant-current vs FET PWM).
I do think it would be nice if users could lightly annotate their uploads as @fizzgig suggested–at the moment some of the spectra are completely unidentifiable.
Opple devices have terribly inaccurate colorimetry from what I’ve seen, which includes a fair number of impossible readings and impossible SPDs. So it’s fair to exclude them from the database. I would trust my eyes more than I do an Opple device.
1 Thank
agree Opple should not be included.. also agree it is sufficiently helpful to have title or notes give some idea of the tested output, as some entries already do
1 Thank
I’m implementing lumens and current fields. They can also be filtered on in the Explore tab. I’m open to include any features. It’s constantly being tweaked and fixed right now.
4 Thanks
I thereby would like to nominate hCRI.io by @fizzgig for consideration by the BLF Gods (@sb56637) for inclusion in the BLF Hall of Fame.
Good idea, thanks!
1 Thank
Nitpicking question: for the away-from-zero warning colour-coding of the Duv button on cards, is the threshold ±0.006 for going from green to orange? Does it ever turn red?
p.s. The neutral/green/rosy indicator uses ±0.002 threshold, I figured?
There is a new public profile for: ‘M21K E90 reflector - DD70 max ramp’.
Can anyone decipher what E90 and DD70 may mean? What’s the LED?
E90 is likely the reflector from a Firefly E90.
DD70 is a DayDream high cri, high output LED.
1 Thank
On the TM30 vector circle: how does the Rg affect the plot? Say the Rf is close to a 100 and produces nice uniform round circle - should Rg correspond to the size of it to indicate higher or lower saturation?
The colour vector graphic on hCRI.io was plotting the wrong quantity. The red polygon was drawn from Rf,hj — per-hue fidelity — instead of the chroma and hue shifts that TM-30-18 specifies. Because fidelity is capped at 100, the polygon could never extend past the reference circle, which meant the graphic was structurally incapable of showing over-saturation: a light with Rg 110 drew a shape inside the circle, reading as under-saturated, while the Rg number next to it said the opposite. It now plots the real thing — radius is the chroma ratio C_test/C_ref, rotated by the hue shift, with reference-to-test arrows — so points outside the circle mean that hue renders more saturated and the polygon’s area matches Rg as it should. All Rf, Rg, CCT, Duv, Ra and R9 values are unchanged; only the graphic was wrong.
Once I deploy the fixes, the existing reports will be recalculated, so any CVG you saved before this date will differ in shape from the same report today. Fixed alongside it: the PDF export’s chroma-shift and hue-shift charts were derived from fidelity rather than the stored per-bin data (the hue chart read 0.00 on every bin for every report), the 99-sample Rf,CES chart was interpolated from the 16 hue bins instead of using the real per-sample values, the PDF’s “reference” spectrum was a flat line rather than the actual reference illuminant, and the CVG polygon was silently absent from every generated PDF due to a malformed path operator.
1 Thank
A search question. Is there a way to search across all the fields?
For instance, I wanted to find all the reports on LHP73B. If I use the search field I get: #830, 832, 833, 834, 520, and 699. If I use LED field I get 520, and 321. I think #321 doesn’t have it in the title, but has it in the LED field.