Bug report - A difference between CP 2.25 and CP 3

[mri0202]

Hello,
I recently installed ColorPerfect version 3 and have been playing around with it a bit. While doing so, I noticed a significant difference between this version and version 2.25 when testing two negatives. Here is an example (film type: Kodak Advantix 200). What can I do to avoid this?

Manfred

Film_054_Bild_024 CP_V225.tif

(116.5 MiB) Downloaded 7 times

Film_054_Bild_024 CP_V_3.tif

(116.5 MiB) Downloaded 7 times

Film_054_Bild_024.tif

(116.49 MiB) Downloaded 6 times

[robyferrero]

Hi,
I tested your negative file with CP3, and this is the result.
I don't know how you scanned it, but it's true that when you open the file in ColorNeg, it appears very contrasty. To achieve this result, I reset the BP, but I didn't turn it off, I just reset it.

[Lucc]

I've tested your file, what camera or scanner have you used?

[C.Oldendorf]

Regarding CP2 and CP3: If you are sure that you have the same FilmType and G/L setup, I will look at this next week.

Regarding Roberto’s image:
There is basically film base in the shadow under the car. Look at this page: https://www.colorperfect.com/noise.html?lang=en It explains what we see noise-wise in the lower part of the car.

Reopen your processed Tiff image in ColorPos mode. Scroll Black down so that Highlight Clipping is 0.01 in this already processed frame. Then zoom in on the shadow under the car and use BP Tails to make that area more or less pitch black. Once BP Tails is set up that way, zoom back out and toggle the BP System on and off to see what this does to the overall color. Your version has a nasty color cast introduced by wrong BP Colors, as you will find.

[C.Oldendorf]

I think the CP2/CP3 difference will come down to working spaces. This used to be the state of things:
https://www.colorperfect.com/working_sp ... ml?lang=en

However, folks insisted on assigning ProPhoto RGB, etc., to color negatives prior to conversion. Long story short: for narrow working spaces such as sRGB, Apple RGB, and ColorMatch RGB, the math in CP3's ColorNeg mode is what it was. For wider-gamut spaces, which include not only ProPhoto RGB but also Adobe RGB 1998, there is a new element compensating for that choice.

After sleeping on it my gut feeling is that we are seeing the interplay of your Adobe RGB 1998 choice, the specifically increased dynamic range of the scene, Black Point, BP Color, and that compensation logic.

It was, and will remain, my recommendation to assign narrow RGB working spaces to color negative scans, as the RGB primaries directly take on the role that the dyes in photographic paper would have had, and that pairing is a better match. There is also no color to be "lost" in this, but that is beyond the scope of what I wanted to write here now.

That would be one thing to do. Assign sRGB and revisit the comparison.

I'll be back with a device that can do imaging and development work on Tuesday

[mri0202]

Hi,
Thanks for the tips. Setting the black point to 0 helped. It worked for other problematic negatives as well. However, CP 2.25 calculates the same black point value as CP 3, yet—as the example above shows—the results are very different. Perhaps this is a clue to the problem.
The negative was scanned on a Nikon Super Coolscan 5000 using Nikon Scan 4.0.3. Only Digital-ICE. Film type: 'Konica Super XG 100, not Kodak,

[C.Oldendorf]

The second thing to try is a two-phase process for Adobe RGB.

Set the image roughly as you like it in ColorNeg mode. Perhaps lower the overall FilmGamma for Advantix 200 by pressing the FilmType button and then scrolling Film Gamma. I would try something in the vicinity of 1.5 for the higher ones; there is a readout in the lower right of the UI when scrolling FilmGamma.

The built-in data is from Kodak's charts, but development factors in, and this sort of gang-scrolling adjustment can help.

Anyway, after that, make sure the highlights do not clip by scrolling Black to whatever degree achieves that. There is no harm in overdoing it. After that, turn off the Black Point System altogether and OK out.

Then, in a second step, in ColorPos mode, set up brightness, Black Point zones, and everything else, and see what that does for you.

The sequence of things is fickle.
I will need to look at it algorithmically; I am not sure yet what will come of it.

[robyferrero]

You can actually see the film in my shadows.
These are two new examples, both set to Kodak Advantix 200, because I made the first one, the one with BP OFF, yesterday. For the second example, I took the BP OFF and loaded it into ColorPOS for further adjustments.
Regardless of the FilmType/SubType/FilmGamma I didn't use, I might have loaded it into TouchUp instead of ColorPOS?
In any case, I eliminated the film effect in the first one, and the second one has a bit more volume.

[mri0202]

I think the CP2/CP3 difference will come down to working spaces. This used to be the state of things:
https://www.colorperfect.com/working_sp ... ml?lang=en

....
It was, and will remain, my recommendation to assign narrow RGB working spaces to color negative scans, as the RGB primaries directly take on the role that the dyes in photographic paper would have had, and that pairing is a better match. There is also no color to be "lost" in this, but that is beyond the scope of what I wanted to write here now.

I assigned the sRGB color space to the negative scans. Unfortunately, the result didn't change at all. Here are a few more comparisons of the black points. I'd be happy to share the negative scans.
CP3 CP2.25
Bild_08: 0.0268 0,0179
Bild_24: 0.1524 0,0162 (uploaded negative)
Bild_27: 0.0267 0,0275
Bild_32: 0.2701 0,1746 (an airplane in the sky)


To this day, I still haven’t grasped the secrets of photography (color space, black points, highlights, shadows, etc.). I admire the people who created such great tools as ‘Colorperfect’ to make my life easier and helped me archive about 4,000 family photos.

[Scandiscanner]

I’ve also recently come across some scans behaving similarly, where CP 3 sets a completely incorrect black point. I don’t remember running into this issue before. I’ve mostly been using sRGB, so I don’t think that’s the root cause either. Following.

[C.Oldendorf]

I'm back from my short trip and have looked at this briefly.
For now, I'll just post what I saved while doing so.

[Full image link - opens in new tab]

I did make screenshots to revisit later. This is the sRGB thought. If the gut feeling that wide profiles are involved in what you saw holds up, I will need to look at that on a subsequent day.

[C.Oldendorf]

Addendum: I think this is a bug after all.

When I started working on the above, I assigned sRGB, called CP, and it came up in PerfectRAW because of my previous use on Roberto's cliff image with the two gulls and my rose example. I switched to ColorNeg and did what I did without any bumps in the road.

Now, by chance, I tried again. If we start in ColorNeg mode, we get the problem initially reported here. If we use PerfectRAW again to make it the starting mode and retry afterwards, there is no problem.

Well, I'll dig into this tomorrow, I suppose. But do remind me to post about the use of a gradient mask to emulate a graduated ND filter in capture for scenes like this that get brighter in one direction.

[C.Oldendorf]

I found that the underlying reason for the observed difference I mentioned was in the fairly new frame detection.

Perhaps it was not the best idea to introduce that so late in the process, but the idea had enough merit, since for some reason it seems unintuitive to new users to crop to the negative area before use, and the results could be ghoulish if they did not.

In any event, I tried to replace the approach in question with a more nuanced and careful idea that should still work for a reasonable group of images while avoiding the behavior we have been discussing here. I hope.

I sent a nightly version of CP to everyone who has actively contributed to this thread. We'll see how far it has progressed.

It is expected that you will have to re-enter your keys. That is unrelated and due to another area that needed attention, but it is beyond the scope of this thread.

[robyferrero]

Being able to work with the edge of the negative without it affecting the curve calculation is a useful option for many.
Personally, I always exclude it, but I have some images—specifically, some I take with a Holga camera or a pinhole camera—that I like to have with the edge of the negative.
However, in this example I used for testing, it's a Leica frame reproduced with the Fujifilm 27mm 2.8 lens: the lens performs admirably, but you can see the barrel distortion typical of modern digital lenses, which I purposely didn't correct to preserve as much of the edge as possible.

In summary: as far as the test is concerned, the edge of the negative didn't cause me any problems with file management.

In conclusion, I'd like to add that these colors, especially the purple, are all thanks to the DC function.

[C.Oldendorf]

Being able to work with the edge of the negative without it affecting the curve calculation is a useful option for many.

I should add that we have always had this ability in CP3; one simply needs to know what to do. If you draw a rough selection over the negative area, making sure not to include anything outside it, and then press and hold the Shift key while calling ColorPerfect, exactly the portion of the overall image you selected will be used for all initial and automatic computations. For problem images, you can always define the image area this way. The main hope with frame detection is to make this more accessible for new users.

[Scandiscanner]

Here is an image I had problems with. At first I thought it was the light leak in the upper part throwing CP off. But then I noticed I could get CP to behave normally when cropping either the upper or the lower part of the image.

The scan is made on a Pakon f135 and converted with MakeTiff. Film is Vision3 250D developed in c41. But I had similar problems on some images on a roll of ultramax recently as well. This is with the build you sent a few days ago.

My work around was crop and convert with CP, then I restored the original crop and used the "exact" option on the full image.

[robyferrero]

[Full image link - opens in new tab]

That's how it came out for me. I haven't done much film testing. After looking at some Kodak films, I went straight to Fujifilm, and I assume it can be better.
You can download the attached TIFF file for a better look.

[Lucc]

It woul be nice if you'd share the original file straight from the scanner.

[Scandiscanner]

That's how it came out for me.

Does it look like that on your side when you simply open it in CP, without making any adjustments?

On my side, it opens with a significant amount of black clipping (and white clipping as well), that I can't reduce to any sane level it by adjusting the BP tails. Interestingly, if I crop the image, CP suddenly seems able to establish a much more reasonable black point.

Just to clarify, my concern isn't whether the image looks good or bad. The issue is that the black point appears to be set to a completely incorrect value.

[Scandiscanner]

It woul be nice if you'd share the original file straight from the scanner.

I sort of did. The Pakon outputs a .RAW file, but Photoshop can't read that format directly. You need to run it through MakeTiff first, which makes the RGB data in the file readable to Photoshop.

(This isn't related to camera RAW files, it's simply the format the Pakon uses to store the scan data.)

[Scandiscanner]

This is what I get if I crop, run CP, go back to the full crop, and then use the "Exact" option. Looks kind of ok now. But why?

[C.Oldendorf]

First:
Thank you for posting this example,
It is precisely the example that is helping me see where I need to do better still in terms of detecting a potentially harmful outside.
I won't go into it, I'll just try to fix it.

Second:
You do not need to crop anything:

One simply needs to know what to do. If you draw a rough selection over the negative area, making sure not to include anything outside it, and then press and hold the Shift key while calling ColorPerfect, exactly the portion of the overall image you selected will be used for all initial and automatic computations. For problem images, you can always define the image area this way. The main hope with frame detection is to make this more accessible for new users.

[robyferrero]

[citazione]Ecco come è venuto fuori per me. [/citazione]
Sembra così dalla tua parte quando l'apri semplicemente in CP, senza alcuna regolazione?[ /citazione]

Quando lo apro in ColorNEG appare così (istogramma allegato). Quando resetto il BP (ON) appare così (istogramma allegato).
I inserted the histogram in the post of the first photo.

[robyferrero]

Here's another version that should have better color.
I'm also attaching the TIFF file.

[Full image link - opens in new tab]

[Scandiscanner]

First:
Thank you for posting this example,
It is precisely the example that is helping me see where I need to do better still in terms of detecting a potentially harmful outside.
I won't go into it, I'll just try to fix it.

Second:
You do not need to crop anything:

I tried to track down the Ultramax images that had similar issues, but I couldn't reproduce it. Either your latest build fixed enough of the problem that they now work correctly, or I misremembered which roll it was.

If I run into any more problematic scans, I'll post them here.

Interestingly, I have an almost identical frame to the one above, taken just a few seconds apart, that behaves completely normally.

And yes, I saw the part about drawing a selection. Nice feature. I mainly wanted to show the workaround I used when I first ran into this image.