Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: "Colorimeter"
Date: Sat, 17 May 2025 12:30:38 -0700
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <100ao53$hkhu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 17 May 2025 21:30:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c53be5ad189e61e289b4809a32a282a3";
	logging-data="578110"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18mGYM3TgS43PZzcWsPzj/T"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0jgo73z1yVDfU8mJQzBHb9WQZ4Y=
Content-Language: en-US
Bytes: 1519

Not quite, but, close enough...

How can I determine the spectrum of incident light on a sensor,
in general?  Then, how many corners can I cut to sacrifice resolution
and accuracy?

I've worked with true colorimeters (dual wavelength) in the past.
But, they were optimized to look for specific wavelengths.

I calibrate the light emitted by my monitors with a device,
but it controls the light source to do so.

With no knowledge of the actual (visible) spectrum impinging on
a sensor (and a bit of time to integrate results), how can I
do this short of swapping individual filters in front of the
sensor(s)?