Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide to_xyz for the emissive case and not just the reflective and transmissive cases #10

Open
faern opened this issue Jan 20, 2024 · 2 comments

Comments

@faern
Copy link
Contributor

faern commented Jan 20, 2024

I'm writing code where I measure light output from various light sources with a spectrometer. And I want to convert this spectral data to XYZ (and other color spaces). But from what I can find this library does not expose spectral data -> XYZ for the emissive case (where no illuminant is supplied, because I'm measuring the illuminant itself). Please tell me if I have misunderstood something :)

I propose adding the following methods (naming bikeshedding welcome):

impl VSPD {
    pub fn to_xyz_emissive(&self, cmf: &CMF) -> XYZf64 {
        // Sum up x, y and z over the spectrum with the three color matching functions
    }
}

impl SPD {
    // ... Same thing
}

I can submit a PR with a proposal. But I wanted a tracking issue where the feature could be discussed (or I can be told this is not needed because of something I have missed).

This function can of course be implemented manually, and that's what I currently do. But I felt it could be a great addition to have it directly in the library.

@KelSolaar
Copy link

KelSolaar commented Jan 20, 2024

You can provide an equal energy illuminant, i.e. 1 at every wavelength, for such case. Ideally, you would want to pass the normalisation factor $k$ too for absolute photometric values.

@faern
Copy link
Contributor Author

faern commented Jan 20, 2024

I thought something like that was possible (thanks for pointing out some useful details around it!). But a dedicated implementation can probably be a lot simpler than the existing to_xyz. I realize of course that some benchmarks would be needed to claim that it would be a performance improvement. I just read the implementation for to_xyz and realize it does a lot of stuff redundantly. Many of the involved VSPDs are aligned multiple times over and over.

Even without any performance benefit, the ergonomics for the library consumer would in and of itself be worth it IMHO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants