that’s a great repository of spectral data, amazing! thank you for sharing it!
1 Like
A bit more to share after making a visualization tool for the camera spectral locus and what actually happens to the camera measurements and how they respond correcting the white balance using traditional RGB channel scaling. hopefully no major errors in the code…
Lets begin with just observing the spectral locus of three cameras that we available in @ggbutcher spectral function repository:
The left subplot should be pretty self explanatory, its the relative sensitivity for each “color” channel of that cameras sensor. The right subplot is similar to a chromaticity plot by projecting the normalized (sum == 1) measurement results onto the plane with normal [1, 1, 1]. Noteworthy remarks:
- Assuming “no noise”, then we know all possible measurements lie inside of the convex full shaped by the monochromatic samples. So its f.ex. possible to be outside of the locus at the top bulge for Z6, but not by much. The important thing is that we, as hantos pointed out has been done in vkdt, do not need to do soft gamut compression by knowing this boundary!
- Any blend between any of those points results in a linear interpolation between them but note that doesn’t mean there is a perfect linear transform between the cameras! This is because the monochromatic positions are different.
- The D700 seems like a really nice camera when it comes to low linearization errors as most of the spectra is clumped into three groups in the corners. But I guess there exist other drawbacks with that kind of approach due it not being used in the more “modern” sensor.
Also made a small interactive app where its possible to “measure” light with our virtual camera and plot it in the camera locus. I generate the spectra for incoming light by reflecting a light source on all diffuse Munsell patches. The colors assigned the camera color and are thus generally green in the same way as when you disable all white balancing in darktable.
The right subplot show where the measured patches ends up if white balance is corrected by traditional RGB channel scaling. Correction factor computed as rgb_{source} / rgb_{destination} Now lets look at two examples of changing the illumination temperature and how the white balance is handled. Chosen cases 5500K (flash) and 1500K (candle). The true D65 illuminated measurements are rendered as light grey behind the experimental results.
Even a small correction from measured at 5500K (left) to corrected D65 (right) shows signs of imperfect results along the boundary but also the purple patches (lower part of the cloud).
The effect is however massive for a candle lit scene! Blues are pushed away and squeezed up against the camera gamut triangle. This will likely show up as early gamut clipping after the input profile in darktable. Reds loose half their saturation and will probably generally look really of to what they should.
Go even extremer and it breaks down even more, here for the Canon 5D mark ii at 1000 K
Back to how this connects to spektrafilm. My conclusion is that it not optimal to do traditional RGB channel scaling for white balance before spectral up scaling as an attempt to normalize the input space. I can also see clearer now why matrix based input device transforms will only work for colors around white as there won’t exist a perfect linear transform from your camera to a standard color space such as REC.2020 or CIE XYZ. This again means that we really need the spectral information about the specific sensor rather than putting effort on spectral priors when upsampling from CIE XYZ, any gains those priors can give us would already be lost in the input matrix errors which I think would look similar as the small white balance errors.
3 Likes
That said, I now feel like building a setup to measure camera spectra sensitivity functions with. Got some build advice from @ggbutcher and I think I have access to most brands of cameras if I ask around with friends and family (know of at least Canon 5D ii, 5D iii, R5, R6; Nikon D700, D7000, D750, Z6 ii, Z8; some Hasselblad model; Sony A7C, A7S iii, A7R V; Panasonic S9)
I think adding those to the already available data could be a nice improvement for estimating the rest from their matrices. Did you follow this paper for estimating non-measured cameras? GitHub - COLOR-Lab-Eilat/Spectral-sensitivity-estimation: Code accompanying the paper "Spectral Sensitivity Estimation Without a Camera" by Solomatov & Akkaynak (ICCP 2023) · GitHub
Method seems promising but I would guess that they have far to validation data to really know how good those estimated results really are.
3 Likes
it’s my understanding that most of these results are hallucinated. i mean vkdt mkssf does the same, maybe not as sophisticated/without neural stuff, so i thought that’s a great resource! i haven’t had much success creating camera input profiles from that data though. the ones i tried resulted in some heavy colour cast. i’m not sure whether this is a simple illuminant issue, like the data is supposed to be camera sensitivity times illuminant/D65 or some such. might also be a normalisation issue. i haven’t followed this further.
2 Likes
<rant>
I find it irritating that the camera manufacturers don’t consider this fundamental data of their products to be important to communicate to their customers. It only has to be measured once, it doesn’t change based on lighting conditions, lens transmission, or anything else. And, it provides a far better basis for making color-representative renders than the janky process of shooting color targets.
</rant>
13 Likes
Hey, I don’t really know how this whole forum works; sorry in advance.
I just uploaded a GPU-optimised Windows version of the GUI with a few additional settings and a dedicated export panel. The speed on my computer for scanning and exporting just got multiplied by 4x but I am planning on going further.
Here is the link
5 Likes
Great work, the speed is indeed an improvement.
this bit made me a bit confused, so - sorry if this is a stupid question but:
“Full 24 MP scan: 41s → 9.4s on the test machine (RTX 4070 SUPER); full-precision export: 4+ minutes → 10.3s”
whats the full precision export? the way I use spektrafilm is that I use the “scan” button and then save the rendered file, which is the first part - am I missing a feature or…? 
“scan-button” = full precision
Any chance these improvements would be easily to ported to Linux? An AppImage (or Flatpak) would be the dream…
thats what I thought and thats why the two different times for whats basically the same thing(?) got me confused
but I guess that its just words, nothing too important
The first thing I did was separate scan from export to prepare for batch exporting. Sorry, it is confusing. Export is full precision float spectral simulation; scan is not. It is still missing a few parameters and is LUT-based, not per-pixel simulation, so it’s lower quality, but it adds grain and halation. The timing is almost the same for both now, and 4x faster than the originals.
For the Linux and Mac builds, I have no idea. The problem is I have neither machine to test on. I might try with Claude Cowork or something similar, since I think their environment runs on Linux.
Batch edit version will be out tonight since it was my first and main goal.
1 Like
Thank you, assuming that that the quality remains identical, this is an absolute gamechanger. On a RTX 5080 exporting 100 megapixel medium format images, the performance improvement is staggering!
I have one suggestion: can you create a new build of spectrafilm.exe against the current HEAD (as opposed to v0.3.2)?
There are a couple of really interesting changes there that have not been added to a new release. Specifically:
-
The preview max size limit has been removed from 999 pixels to basically anything the user wants. This means that you could have a 4K preview if you wanted, which really benefits the acceleration from your implementation.
-
There is a new Print → Chemistry feature which basically gives us far more granular control over colour correction.
Great stuff.
FYI: the full-precision export is described if you hover your mouse over it. The author has added a new ‘export’ category in ‘Main’ that kind of replaces the ‘Save’ button.
4 Likes
I agree with @hinius, an update to the latest version would be great. Print → Chemistry and Base are great features.
1 Like
Wait wait, the legendary Hin Chua? @hinius
This project seems to attract some interesting peeps — welcome to the forum!
2 Likes
ah okay, so the scan button behaves differently than in the python version, I think I understand it now! (haha I did not - the new export section behaves differently, the scan/save is the same :D)
anyway, I second the thing others mentioned - please consider building it from an updated version, or even better - from the reflectance-upsampling-methods branch, the new tools included make a big difference
Posting Batch editing now based on version 3.2, I’ll update to the last version tomorrow or in the next days depending on the amount of time it takes.
4 Likes
checked the last version, I like the batch editing, though I probably wont fit it into my workflow, at least for now. but the time saves are really impressive, especially for 45+mpx files haha.
any chance you could make a version based on the reflectance-upsampling-methods = 28bf883 tree?
edit: the branch is called experimental now
edit2: why is the output gamut compression running on cpu?
1 Like
I agree, the speed is impressive. The histogram and the film curve are nice additions. I also like that I can see the photo resolution. Keep up the great work!
1 Like