on.raw.photography

robyferrero wrote: Sun May 31, 2026 10:41 am Here's another version that should have better color.
I'm also attaching the TIFF file.ColorNEG BP ON ZERO.png

Yes, that looks better. Though I think Christoph has now confirmed that the issue is actually in the detection code.

An update on this.

I have spent considerably more time on the frame-detection question over the last couple of days than I originally intended. The extended test set has made one thing fairly clear: the comparatively simple sensitometric, or density-/brightness-based, approach I had hoped might be sufficient is not robust enough in the real world.

That approach was attractive because it was maintainable, comparatively straightforward to implement, and did not require a large amount of additional machinery. Unfortunately, the edge cases are not merely theoretical. There is no truly reliable way, from such measurements alone, to distinguish all cases of actual film base, holder, mask, light source, and rebate from image content that happens to have similar measured properties. A nearly unexposed area in the image, a black shirt, or, conversely, a bright window area can at times look too much like something outside the intended image frame. If the feature is meant to help, rather than silently make wrong assumptions, that is not good enough.

So I have removed the frame-detection work that existed in the previous test builds and started again from a more explicitly geometric approach to detecting the actual image frame. That is a much more complex route, both in terms of implementation and in terms of making it fast enough to be acceptable at plug-in startup, but if we are to keep the feature, I do not see a dependable alternative if it is to work across a useful range of real scans and repro photographs.

In retrospect, I probably should have said “no, thank you” when this feature request first came up. But it was an interesting problem, and as so often with interesting problems, one then finds oneself rather deeper in it than planned.

The good news is that the rewrite has made real progress. This morning I still expected the performance work, especially making the detection fast enough in practice, to take substantially longer. It has been a long day, but the current version has advanced far enough that I think it is worth letting those who contributed to this discussion try a first new build.

I will therefore send the current test build to the active participants in this thread next. I am mainly interested in seeing how it behaves on a wider range of real material; on the dozen or so test and edge cases tried so far, it already holds up very well.

These are two tests of a black-and-white negative shot with a glass-lens Holga camera and a color slide under critical lighting. It seems to me that CP performed well with both the mixed (black and white) and black borders.

Seems to handle the uncropped scans from a Coolscan 4000 well.
But I found some other files that did cause problems. Will post them shortly.

Scandiscanner wrote: Tue Jun 02, 2026 3:17 pm But I found some other files that did cause problems. Will post them shortly.

Nice, maybe something can be learned from them.

These are two scans from the same roll as the problematic scan I uploaded earlier. What's peculiar is that the first image was taken only seconds apart from the previous frame. In earlier builds, this image looked quite normal, while the other one had the issue. In the new build, the behavior seems to have reversed: this image now has very aggressive black and white points, but the previous image looks normal.

The other image also shows a very aggressive black point.

I fired up Rosetta to compare against CP2:

Then some Fuji Xtra 400 frames.

Again I compared to CP2:

Scandiscanner wrote: Tue Jun 02, 2026 5:32 pm Then some Fuji Xtra 400 frames.

Wonderful, thank you. I already have a bunch of qualifiers to assess if a geometry is a frame or may be a window in the photo for example only I lacked a feeling for what values to use as thresholds. I suppose I'll fine tune this some more tomorrow, make a binary and we'll see if we can come up with a failure example after that. Right now your new examples behave as do the actual film or mask surrounded ones.

OK, looking forward to that. I'm guessing the the detection as it is now behaves better on scans with actual film borders and masks, and the problematic images will be scans like mine, with no mask or film base in the frame.

The Fuji roll is behaving well now with last nights build. I have more similar shots on that roll.
But this image still has some problems I would say. Comparison with CP2 here:

These two frames have some problems as well. Windows seem to be a theme.

Maybe this one as well. It behaves rather differently if you crop away the mask.

Maybe I missed something. Now the problem is when you crop the black border of the frame?
Do you mean, if we load a file with a black border into CP3, the base curve appears consistent, but when we crop the black border, the base curve goes haywire?

robyferrero wrote: Fri Jun 05, 2026 10:09 am Maybe I missed something. Now the problem is when you crop the black border of the frame?
Do you mean, if we load a file with a black border into CP3, the base curve appears consistent, but when we crop the black border, the base curve goes haywire?

If you're referring to the last image I posted: cropping the frame gives the expected behavior, but loading the entire image with the mask seems to confuse the algorithm.

In more general terms, I'm just trying to find images that tricks the algorithm so Christoph can use them to improve it. I imagine building a foolproof algorithm that always knows what's part of the image content and what isn't is a pretty hard problem. There are probably a lot of edge cases.

Okay, so I misunderstood your last post. You know how it is, translations are sometimes flawed.
It could be that there are some edge cases that fool the algorithm. I haven't encountered any yet involving the edges of the frame, but apparently it can happen.
The important thing is that if you need that image today, without waiting for tomorrow, regardless of the algorithm's flaw, you can still get it by excluding the BP and managing all the adjustments yourself.
In any case, you're obviously right to find some complicated files so that Christoph can solve the problem.

My comment was a bit unclear. What I was trying to say is that if the detection is working properly, cropping the orange mask shouldn't affect the result.

That said, I think you're probably right that the issue seems more common with images that don't have a mask or film holder, where the algorithm mistakenly treats part of the image area as "outside" the image.
Either way, it's good to know there are workarounds if you need to process an image right away.

Scandiscanner wrote: Fri Jun 05, 2026 1:23 pm In more general terms, I'm just trying to find images that tricks the algorithm so Christoph can use them to improve it. I imagine building a foolproof algorithm that always knows what's part of the image content and what isn't is a pretty hard problem. There are probably a lot of edge cases.

Thank you so much for that, too. It is very helpful. I don't know where this feature is headed.
I thought it should be possible to harden it enough with "some" effort, well, little did I know.

I have sent a new build to everyone active on this. It tackles the false-positive cases presented here while still working reasonably well on actual negatives. Furthermore, it no longer has any impact on modes outside of ColorNeg.

From here, I think there are two possible paths. If it holds up well enough, it can stay in production. If it does not, and cannot be made to, it could also be limited to the stage before license-key entry. One group I would really like to take complexity away from is new users, after all. Everyone else already had all the means needed; one only had to know about them.

In the future, maybe it could be configurable, but for CP3, no more interface work.

It seems to work a lot better now, based on my admittedly limited testing so far. I’ll continue to post scans if I come across any problematic cases.

I think there’s a real possibility that edge cases will always exist, given the wide variation in how people scan images and the diversity of photographic material. That said, the feature is genuinely very useful.

A pragmatic approach might be to add a simple setting that allows users to turn the feature on or off as needed. Just my 50 cents.

It might also make sense to disable the feature when using the "make selection and open CP while holding down the Shift key" method you suggested earlier in the thread.

In that case, the user is already explicitly defining which part of the image CP should use as the basis for its analysis, making the feature unnecessary in that particular workflow. Disabling the feature in that specific case would also help avoid unintended adjustments and give users more predictable control over the process.

Scandiscanner wrote: Tue Jun 09, 2026 4:34 pm It might also make sense to disable the feature when using the "make selection and open CP while holding down the Shift key" method you suggested earlier in the thread.

It always has been that way. That is the whole point of that feature The selection gets heeded no matter what.

---

Scandiscanner wrote: Tue Jun 09, 2026 4:17 pm A pragmatic approach might be to add a simple setting that allows users to turn the feature on or off as needed. Just my 50 cents.

=>

C.Oldendorf wrote: Sun Jun 07, 2026 8:44 pm In the future, maybe it could be configurable, but for CP3, no more interface work.

---

Scandiscanner wrote: Tue Jun 09, 2026 4:17 pm I think there’s a real possibility that edge cases will always exist, given the wide variation in how people scan images and the diversity of photographic material. That said, the feature is genuinely very useful.

That is so for sure. In this early phase of trying this the point of looking at edge cases was that they might allow generalization of what happens why and how to be more specific and strict in terms of what we seek it to do. There will also be the opposite: Real frames that do not get detected and still ruin the positive image.