I built a free TM-30 color rendering analyzer — upload your spectrometer CSV and get a full report instantly
Hey everyone, I’ve been building hCRI.io and it’s finally ready to share.
If you’ve ever wanted to go beyond CRI and actually understand how a light source renders color, this is for you. Upload a spectral power distribution file from your spectrometer (Hopoocolor HPCS-330, HPCS-600, or any CSV/JSON/CGATS format) and get a complete IES TM-30-18 analysis in seconds.
What you get:
- Rf (Color Fidelity) and Rg (Color Gamut) per TM-30-18
- CCT, Duv, Ra (CRI), and R9
- Color Vector Graphic showing per-hue chroma and hue shift
- Local fidelity bars for all 16 hue bins and all 99 CES samples
- CIE 1931, CIE 1960, CIE 1976, and SDCM MacAdam ellipse chromaticity diagrams
- Shareable report links and downloadable PDF + PNG share cards
- Instrument metadata extracted automatically from file headers
Guest mode works without an account. Create a free account to save reports and compare sources.
https://www.hcri.io
Would love feedback from anyone doing serious lighting evaluation — flashlight enthusiasts, photographers, lighting designers, or anyone nerdy enough to own a spectrometer.
7 Thanks
Wow, this is a great resource! Browsed the SFT40 3000K report and it looks pretty nice. A couple points:
- Is there some obstruction to computing the full R1-R15 values? If not, I would strongly recommend implementing them, especially R12 (saturated blue). LEDs nowadays are getting good enough that low R9 is no longer a concern among most high CRI emitters; however, most emitters still struggle with R12, and some perform noticeably better than others, e.g., SFT40 vs 519A 3000K.
- In the SPD plot, how is the reference spectrum (dotted) normalized? It looks substantially different from both the test spectrum and the normalization generated by whichever device koef3 used:
As-is, the normalization does not appear to be equal-brightness (luminous flux), nor equal area, nor equal power–it looks like the dotted line simply matches the height of the peak wavelength, which is not a useful normalization in this context. If I had to guess, the appropriate normalization should probably be equal-brightness, in order to avoid capturing the huge discrepancy in the far-red and near-IR region.
- Additionally, the dotted line seems to have some analytic oddities inconsistent with a blackbody spectrum, such as the nonzero plateau under 400nm and the sudden transition to flatness near 800nm. Being a blackbody, the reference spectrum should (i) be smooth without sudden turns, and (ii) decay toward 0 at the tails, in this case the near-UV tail. Perhaps a wrong equation was used, or some graphic settings did not behave as intended.
I will definitely take a look.
Lots of updates have been made to expand the ease of use and functionality. Hopefully more data is populated soon for the gallery.
1 Thank
I see that many issues have been fixed and that more features have been introduced–thanks so much! It was nice browsing through the community contributions. Two more minor items if you have time:
- For 5000K and above, the reference is generally taken to be some daylight/blackbody mixture, rather than pure blackbody. At the moment, it looks like blackbody is used for all CCTs.
- More of an isolated incident: I’m not sure what emitter this is, but the spiky spectrum definitely should not receive an R12 score of 99!
The raw data is at the bottom. I’ll feed it into color calculator to see what it comes up with.
1 Thank
I re-ran it with the downloaded data, and the R12 stayed the same, but R9 and R10 changed! This should definitely not happen:
What did you run it through? Different things use different methods. With a few points is not much different.
I downloaded the data csv, and uploaded it in guest mode. Since colorimetry readings are a deterministic function of the spectrum data, every run should yield identical values, and any deviation is indication that something is off. A 3-point deviation in R9 is more than explainable by rounding error.
But mostly, I’m concerned because the R12 value of 99 attracts suspicion, due to how spikey the spectrum is in the blue region. I’ve never seen a blue-pumped LED >5000K score >90 in R12, so this is almost surely a mistake.
I’ll dig into it tomorrow. Did you just upload the NM values or the full report? If the r values are provided by the device it uses those as a priority. I’ll see what it’s doing.
1 Thank
I downloaded+uploaded the full csv file, which does have some existing colorimetry values in the first few rows–could that be messing with the calculator?
But then, the values already in the csv (5840K, -0.00013duv) don’t exactly agree with the calculator output (5847K, -0.0002duv).
Much appreciated!
The device values will always be slightly different. Maybe u should ignore device values and just use a consistent measure.
I’m happy to ignore the device values, my concern is that the following two values are different:
- Your calculator output when I’m just browsing others’ uploads
- Your calculator output when I downloaded that uploaded data and re-uploaded, which shouldn’t change the data at all.
I would like to use your calculator output as a consistent measure, but at the moment it seems self-inconsistent, outputting 2 sets of measurements for the same data. Additionally, the concern about the abnormally high R12 remains.
can you check now? I also need to figure out the other issue you mentioned. If it’s still an issue.
All of the data is now being calculated from the wavelength values rather than using any of the values from the meta data.
1 Thank
I just checked–now the browsed data and uploaded data seem to have identical readings. Many thanks for the fix!
I wish I could offer more insight about the weird 99 R12 issue, but it seems like an isolated or oddly-specific bug as R12 values for the other spectra I’ve seen look reasonable.
I fixed the r12 issue inconsistency. Can you explain the 5000k and up issue more? Is that still a problem?
1 Thank
It is indeed fixed–thank you very much! For my understanding: what was the cause of the R12 issue?
Yes, about the >5000K thing: below 5000K, the reference spectrum is taken to be the blackbody spectrum of corresponding CCT–nothing complicated here, and the spectrum even has a closed-form formula.
Above 5000K, however, the target/reference spectrum is no longer taken to be the blackbody spectrum, but a D series (daylight) illuminant. This can be thought of as a blackbody spectrum that has been filtered by the stellar and terrestrial atmospheres, so there are all sort of irregularities like dips and turns. You can see some of these irregularities in the reference spectrum (blue) from koef3’s LED tests:
The fact that the reference spectrum from your calculator looks smooth rather than jagged suggests that it is a blackbody curve:
If you think of any additional measurements I should add, ler me know.
1 Thank
The r12 issues was just a bug in the calculations. The r9 value was the system using the device values as a priority. Now it only uses the spd values for everything for consistency.
1 Thank
Got it, thank you very much for explaining! I will let you know if I think of any more improvements.
There’s some minor wonkiness with extra lines being drawn for some of the spectra, but they don’t mess with my ability to see what I want to see. Strangely, they seem to exclusively happen to spectra that span the full visible spectrum:
