Narrowband - unexpected color results

[seanharding]

I've been doing some experimentation with photos of a color chart, and I've noticed that when scanning with the @jackw01 Big Scanlight, and converting in NegPy, the results are not particularly good.

Here's an example, converted in v0.39.0 (yeah, sorry, forgot to flip it before exporting).

This was a photo shot on Ektacolor Pro 400 (aka Portra 400) in bright sunlight. I think the clearest issue is that on the second row, the colors should be cyan, magenta, yellow, red, green, blue. But the yellow instead looks orange. Maybe it's a failure of my editing skills, but I am not able to figure out what adjustments I can make within NegPy to get this close (and in any case, it seems like the default conversion should be closer than this). The same frame scanned with the white backlight, or with RGB triplets, looks ok. It's just narrowband that looks wrong.

I had the Narrowband setting on for this export, but turning it off doesn't fix the issue. It just increases the saturation of the incorrect colors.

Here is the raw file if anyone wants to play with it.

If there's something stupid I am doing wrong, please let me know.

[marcinz606]

Hi, that's exactly why crosstalk matrix exists. It's downright impossible to get defaults to work with every scanning setup/stock/development If you have color chart it makes even more sense - you can dial in colors in ~30s, save it it as preset and forget :)

[thetalkingdrum]

#537 got me thinking about the pipeline side of this. The whole negpy pipeline benefits from having a characterization step before the output stage and the tools for it are already there, they're just not really promoted as that. The data coming in is uncharacterized and the defaults are never going to work for every setup like you say.

Density Mixer has mostly been presented as film stock crosstalk correction, but going by your reply here, it sounds like you're already thinking about it the same way I am, something you dial in for your specific setup.

Might be worth emphasizing that more, as I'm not sure it is that obvious right now. Better docs/tooltips pointing people at it as a general characterization step, so they try that instead of opening another "bad color" issue.

I might open a separate discussion on this to go a bit more into detail.

[seanharding]

I played with the crosstalk matrix yesterday and was able to get something somewhat decent, but it required pretty extreme adjustments (pushing some of the sliders near the end of their travel). I didn't spend a ton of time on it, though, so I'll dig in more today.

The crosstalk matrix going to vary depending on film stock too, right? So effectively I'd have to shoot a color chart with every single (color negative) film stock I use, and create a custom matrix for that? Are there other factors that would affect it too, like slight variances in processing, negative density, etc.?

Makes sense on a technical level, and sounds like a hassle on a practical level (and impossible for old rolls that I have in my archives but can no longer get new film to shoot a color chart on). If that's the only answer, I suppose the practical path is, shoot a chart and make a crosstalk matrix for my most common few film stocks, and for anything where I don't have one, scan with white light or use RGB triplets (which IMHO is too time consuming if I'm scanning a whole roll, but is fine for a few frames at a time).

If this is the expected behavior, I do think it's important to have some pretty prominent messaging/documentation to people that they should not necessarily expect Narrowband RGB scanning to give correct results without a custom crosstalk matrix. I suppose maybe something is weird about my setup, but I don't think it's that exotic, and these colors are far enough off that I wouldn't want to encourage people to use images that come out like that.

Somehow NLP managed to get pretty close to correct colors out of this frame without any manual tweaking at all, but maybe that was just luck (because I have definitely had egregiously bad conversions from NLP on narrowband RGB images).

[thetalkingdrum]

The difference between film stocks are quite small compared to the rest of your set up. So in theory yes, you would have to shoot a chart for every film stock (but the same goes for white light if you want to be picky).

But in practice it is probably not going to make a huge difference. If you manage to get one good profile it will most likely work well for most other color stocks too. You do not need a separate profile for every film stock in other scenarios so I can’t image this would be much different.

I’ve seen similar results with hues that are very far off with NLP when narrowband camera scanning with single shot. It seems to go with the territory. It is always going to be a combination of light source and sensor response. I think there is no way around profiling if your particular setup gives strange colors. But I also don’t think that is a huge hassle. And if you have a color chart you are better off than most.

[thetalkingdrum]

But I agree that this should be documented better as I alluded to in my previous post.

If you have a pipeline that is uncalibrated, but meant to take input form a huge range of different setups, you are going to run into issues like these. Then it should be easy to find documentation on what steps to do.

But I mean, things are being figured out along the way. Narrowband support is only a few weeks old at this point.

[seanharding]

Yeah, for sure, doing a custom matrix once for the setup is not a huge hassle, if that gets me "close enough" results. I guess the presence of custom matrices for so many film stocks in the app lead me to believe that the differences are significant, but I didn't dig into them to look at how different they are. And I suppose if I come up with a baseline for my setup, I can always do tweaked versions of it if I do find a film that needs a bit of adjustment.

[seanharding]

The other issue I'm noticing with a custom matrix that has large corrections is that on some images it also results in a major change in density. Nothing that can't be corrected, but it does add a bit more work on some frames.

[thetalkingdrum]

I think you are need to re-run batch analysis when you change to a different matrix. Maybe that is part of the density changes you are seeing if you did not re-run?

[seanharding]

Hmm. I have never used any of the roll analysis stuff because I very rarely scan full rolls. Usually I'm scanning just one frame from a roll, or at most 2-3. In these tests it's all been one frame from a roll. Should I still be using batch analysis in that case?

[thetalkingdrum]

OK. Probably no. Can post some examples of the density changes you are seeing? If you have dialed in the density first (with no matrix) and and then turn on the matrix I guess it might happen.

[seanharding]

I'll try to find a good example if I have some time later today. The clearest one I have is a photo of a friend's child, which I don't want to share publicly. But it had no edits (indeed, I wiped out all NegPy settings and edits prior to doing this testing), so I don't think that's it.

[thetalkingdrum]

Just want to get an idea of what these density changes look like and how big they are. So just anything that shows that is good.

[seanharding]

By the way, this is far from ready for prime time, but I'm experimenting with a feature for creating crosstalk matrices from a color chart.

[seanharding]

Alright, on the density question, this is not as dramatic as the other one (with my friend's kid), but I think you can see how much lighter the image looks with the custom crosstalk matrix (the second screenshot).

[jackw01]

This seems to me like a crosstalk issue on the camera sensor side, rather than between the light source and the film. I've gotten plenty of these "bad color" issue reports and yellows shifting towards orange (caused by the camera green channel's sensitivity to blue light) is fairly common, but it's unusual to see it as the most significant color shift. For narrowband single-image scans, the crosstalk matrix becomes more camera-specific than film-specific, since we don't have to worry about the film's light transmission outside each dye layer's peak absorption band, and those don't change much if at all across C-41 films. With light sources where the channels are individually controllable, it's possible to capture images of each color channel on the light source and derive an approximate crosstalk matrix based on how much light is seen by the other channels on the image sensor.

On my Fujifilm X-T30 using the generic ICC profile for the camera and linear RAW profile in Capture One, the normalized RGB values for each color channel on the scanlight v4 / big scanlight look like this:

• Red: [ 1, 0, 0.17 ]
• Green: [ 0, 1, 0.5 ]
• Blue: [ 0, 0.3, 1 ]

I can then transpose and negate these values and enter it as a crosstalk matrix into NegPy. This may not be the most technically accurate approach, but it doesn't require photographing a color checker and it works very well for my needs:

This kind of crosstalk matrix calibration could be built into NegPy using a set of photos of the light source as input, or even fully automated with the camera tethering features.