Also Im not sure how the upsampler works with a native rgb set since its engineered to work with fitted values.
I like the spectral calculations (profiles) in this module, especially the mismatch from neg to positive. Really fun for look dev.
Are you trying to be positive or are you making fun of me?
What made you say that !
Let’s keep it on-topic, we have plenty of real, loving people who genuinely cares here Benjamin ![]()
I’ve noticed you made new commits. Will update the builds tomorrow. Thank you so much!
I’ve seen the github issue was assigned the 5.8 release tag - how likely is it that it’s ready by then? I’m on mac so I can’t play around with the testing builds, but I’m quite fond of the looks spektrafilm is producing so I look forward to having this in darktable
Im actually being nice guys, I truly don’t know what offended you, but sure… better keep this thread on topic. Thank you for your efforts to make these tools for everyone. If you could highlight some points for me on what I wrote, I would be happy to elaborate in the context of this topic. Other than this, I’m truly confused ![]()
Will push the missing checkbox code tomorrow as well now that this part is in master
Sorry if it has been perceived that way. Your writing might have felt somewhat sarcastic in some instances. Sometimes it’s hard to filter it out in a text message exchange. Now that I’m reading it back yes, it’s all fine. Thank you.
@ho4 can’t you play with the testing builds? I’ve been producing them for both macOS Intel and Apple Silicon here if you need to download them. Not sure if this will make its way to 5.8. I think it is definitely possible but I’m just collaborating in refining the implementation wherever I see fit
@piratenpanda by the way, if you could rebase all the commits to current master branch from Darktable, so we can also see how it works with the current state of changes being worked on in Darktable, that would be nice
You point out problems with the module, then appear to be complimenting them. It sounds sarcastic. Like here:
Nothing wrong with pointing out problems with the module at all, it is in development phase, but the developers are in good faith trying to make it better, so an encouraging tone is more helpful than a sarcastic one.
But it seems you didn’t mean it sarcastically, so perhaps the intended meaning was lost in translation.
If the DIR couplers are broken it might be best to give examples how, and especially to compare them to the main spektrafilm project, to see if they behave very differently.
Thank you, I’ll try to write something proper here with some examples.
English is not my first language, I was complimenting the projected as a whole.
Regarding the DIR couplers, it’s not even about this project, it’s actually the sole idea of implementing them in a digital workflow as in for matrixed sensor integrals are very problamatic. I will show you in a minute.
No worries. If it’s not about the darktable implementation specifically, it’s probably best to post problems with the DIR couplers as a whole in either this thread:
Or this one:
The lead developer is very active in those threads.
Every tone mapper needs to be " stress tested", I’m sure most of you here are familliar with the module and what is the essence of it, which is the primaries controls… scaling the basis vectors aka insets and rotations. Spektrafilm adopted this ideas and the gaurdrail is behaving really good, but when we introduce the DIR couplers we start to notice the issues I was referring to !
Here is the rgb sweep whe tested using this module :
For these I used Fuji C200 with Fuji crystal but it doesnt matter much, no halation and grain too. So, these samples go from 0 to 2 in 0.5 increaments, and you can clearly observe how they are destroying the gradients !
Other examples :
The first sample is not tone mapped to clearly showcase. Again, from 0 to 2 in 0.5 increaments.
Now, let me explain what I meant by using this module with camera native rgb, embedded matrices that are delivered from camera manufacturers are more than often problamatic, since they introduce negative values (out of gamut clipping), therefore the need of gamut mapping and so on, that’s why we need the guardrail (inset and rotations) in the first place. The problem is, it’s not just negative values and mapped back, it’s way worse ! Let me show you, the following examples are provided from Satirio Barselino (maestro) and they showcase the issues of the camera matrices in extreme lighting conditions :
the reflections on the ground are an additive phenomena, in simple terms they should appear lighter than the source… and it’s the opposite here !
But if we use the native records of the sensors, we don’t seem to face these issues :
SEE: Daniele Siragusano’s video about additive mixtures for further info.
My point is, that’s why introducing the inhibitors is a bad idea in the first place because camera matrices are problematic in themselves ! And btw, this goes for all additive pheromones like transparency, glare you name it.
If you do this in the original Spektrafilm code it will also break somewhere at or above 1 depending on the stock. This is the correct math but should be limited to 1 as I now did with the latest commit.
I don’t understand what you mean. Darktable uses Adobe color matrices for their input color matrices. I don’t seem to have cameras with a problematic one. To what did you set the input color profile instead? And can you provide a sample raw maybe which shows this issue?
I think these two topics are simply things that hasnt been solved over at the original spektrafilm implementation yet and not a problem with the darktable mirroring implementation. Havent looked at how the couplers work but I have spent some time with that input matrix problem, see spektrafilm tech discussions for more in depth discussions on how to solve it.














