You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EOS Rebel T6 w/ 50mm F2.5 macro lens & iPhone 17 Pro with macro lens
Light source
Lomography Digitiliza
Correction mode
Not sure / didn't touch this setting
Input ICC profile (if any)
N/A
Relevant process-tab settings
No response
What happened
Whenever I drag in a scan of a negative, the automatic inversion ends up very dark and blue. There doesn't seem to be anything I can do to change it. Negpy used to work flawlessly for me in the past but it's been doing this for the last few months or so.
I think you're getting burned by the whole frame being very dark and there being no even-less-dense border for the metering to notice when calculating D_min.
Also, I was able to recover a decent amount of luminance that might be close to what you expected, by dragging the Luma Range Clip slider (on the Roll tab's Metering section) all the way to the right. Maybe that's evidence that the metering is out of whack because there's no rebate.
Your image use build-in Apple Wide Color Sharing Profile.icc. Profile use build-in Lut and non linear gamma. This makes negative invert incorrect, even if invert manually in other app.
If set P3 profile with linear gamma to image it start to invert as expected, but colors will be incorrect because P3 have different color gamut i guess.
But even with attached P3 linear profile and maximized Black and White points NegPy still auto detects it too dark. I guess image itself simply underexposed and dark and NegPy can't automatically create day(or evening) from night in same way as i done it manually.
It start to look better if set smaller area for Analysis buffer. Overall i guess problem is due shitty camera and light source, which produce huge amount vignetting and low CRI colors, which lead to incorrect auto detection.
So it's just the quality of the scan? In the past, Negpy has done amazingly on scans with this light source and a worse camera. Unfortunately I don't have a version with the rebate because the entire film strip was exposed (sprockets and all). I thought Negpy worked best when the image was cropped down just to the exposed area though (at least at one point.
NegPy expects linear gamma scans. And this one is looks like it was gamma corrected. So invert will be incorrect in NegPy (because it ignores input profile) and more less correct (but actually also incorrect in own way) in Lr (because Lr can read input profile).
Image ICC profile still ignored by NegPy, so it is still hard to understand which color management logic used in NegPy for broadband light sources. it is only possible to adjust colors by guess. It looks like they interested only in Trichome and RGB LED light sources calibration. See my post #1225
So it's just the quality of the scan? In the past, Negpy has done amazingly on scans with this light source and a worse camera. Unfortunately I don't have a version with the rebate because the entire film strip was exposed (sprockets and all). I thought Negpy worked best when the image was cropped down just to the exposed area though (at least at one point.
What was the last version of NegPy that worked okay for you? It should be easy enough to look at the commit history to see what was introduced in the release after that to make your gamma-corrected scan no longer squeak through against the formal expectation that it wouldn't.
(How are you ending up with TIFF format files here rather than linear RAWs, BTW?)
So it's just the quality of the scan? In the past, Negpy has done amazingly on scans with this light source and a worse camera. Unfortunately I don't have a version with the rebate because the entire film strip was exposed (sprockets and all). I thought Negpy worked best when the image was cropped down just to the exposed area though (at least at one point.
What was the last version of NegPy that worked okay for you? It should be easy enough to look at the commit history to see what was introduced in the release after that to make your gamma-corrected scan no longer squeak through against the formal expectation that it wouldn't.
(How are you ending up with TIFF format files here rather than linear RAWs, BTW?)
I'll go have a look at the last release that worked. It was a while ago. The TIFF files are just a byproduct of how I cropped the scans after the fact (I used the Mac photos app to crop but to get it out of photos and maintain quality you have to export and I think it was either TIFF or jpg). I could probably maintain the canon raw files if I just altered that process
@matthoosier the last version that worked for me was 0.13.2 but I think the real issue here is likely the TIFFs, I also noticed that some negatives that failed for me in the past were erroneously saved as JPGs before being put into negpy. When it worked in the past I think I was using DNG's (Apple's raw format) I'll try again with the actual raw files and reopen this if I have more issues. Thanks!
You use too confused workflow. Transform from linear raw to tiff by Apple converter which converts gamma and color space and sets Lut-based icc profile is very bad starting point for negatives.
Same time using RAW directly in NegPy which ignore input profile is also bad idea, because colors always will be wrong. You need custom made ICC profile and Crosstalk correction for this. Currently both tools are not ready or not comfortable:
TIFF/RAW ICC/Matrix profile ignored.
There are no sliders to set Input matrix manually.
Crosstalk correction applied before all corrections and hidden somewhere deep inside, so it is impossible to interactively adjust it manually.
Here is one more experiment. Instead of assign P3 gamma1.0 profile (which was incorrect), i converted from Apple Wide Color Sharing Profile to P3 gamma1.0 and processed as usual. Tonality behave predictable and colors are more-less OK. Markers show wherw i pick black point for film base Levels and gray point for R/B gamma adjustment.
Tried it again with RAW files and with JPGs. Sometimes the JPGs work but sometimes not. I've found more success with using the RAWs and cropping/rotating in Negpy. Works like it used to and I get results I'm happy with. So this was just user error 👍. Thanks for the help!
Activity
[-][Bug]: Negative Insersion Unusable[/-][+][Bug]: Negative Inversion Unusable[/+]matthoosier commentedon Oct 12, 2026
Do you have a copy with the rebate intact?
I think you're getting burned by the whole frame being very dark and there being no even-less-dense border for the metering to notice when calculating D_min.
Also, I was able to recover a decent amount of luminance that might be close to what you expected, by dragging the Luma Range Clip slider (on the Roll tab's Metering section) all the way to the right. Maybe that's evidence that the metering is out of whack because there's no rebate.
radioproektor commentedon Oct 12, 2026
Your image use build-in Apple Wide Color Sharing Profile.icc. Profile use build-in Lut and non linear gamma. This makes negative invert incorrect, even if invert manually in other app.


If set P3 profile with linear gamma to image it start to invert as expected, but colors will be incorrect because P3 have different color gamut i guess.

radioproektor commentedon Oct 12, 2026
By the way, P3 and Apple Wide Color Sharing Profile gamuts are close enough

radioproektor commentedon Oct 12, 2026
This is in manually processed in PhotoLine with attached P3 linear profile.

radioproektor commentedon Oct 12, 2026
But even with attached P3 linear profile and maximized Black and White points NegPy still auto detects it too dark. I guess image itself simply underexposed and dark and NegPy can't automatically create day(or evening) from night in same way as i done it manually.

radioproektor commentedon Oct 12, 2026
It start to look better if set smaller area for Analysis buffer. Overall i guess problem is due shitty camera and light source, which produce huge amount vignetting and low CRI colors, which lead to incorrect auto detection.

jakegriffey commentedon Oct 12, 2026
So it's just the quality of the scan? In the past, Negpy has done amazingly on scans with this light source and a worse camera. Unfortunately I don't have a version with the rebate because the entire film strip was exposed (sprockets and all). I thought Negpy worked best when the image was cropped down just to the exposed area though (at least at one point.
jakegriffey commentedon Oct 12, 2026
I was able to get this just by manually inverting using light room

radioproektor commentedon Oct 12, 2026
NegPy expects linear gamma scans. And this one is looks like it was gamma corrected. So invert will be incorrect in NegPy (because it ignores input profile) and more less correct (but actually also incorrect in own way) in Lr (because Lr can read input profile).
Image ICC profile still ignored by NegPy, so it is still hard to understand which color management logic used in NegPy for broadband light sources. it is only possible to adjust colors by guess. It looks like they interested only in Trichome and RGB LED light sources calibration. See my post #1225
matthoosier commentedon Oct 12, 2026
What was the last version of NegPy that worked okay for you? It should be easy enough to look at the commit history to see what was introduced in the release after that to make your gamma-corrected scan no longer squeak through against the formal expectation that it wouldn't.
(How are you ending up with TIFF format files here rather than linear RAWs, BTW?)
jakegriffey commentedon Oct 12, 2026
I'll go have a look at the last release that worked. It was a while ago. The TIFF files are just a byproduct of how I cropped the scans after the fact (I used the Mac photos app to crop but to get it out of photos and maintain quality you have to export and I think it was either TIFF or jpg). I could probably maintain the canon raw files if I just altered that process
jakegriffey commentedon Oct 12, 2026
@matthoosier the last version that worked for me was 0.13.2 but I think the real issue here is likely the TIFFs, I also noticed that some negatives that failed for me in the past were erroneously saved as JPGs before being put into negpy. When it worked in the past I think I was using DNG's (Apple's raw format) I'll try again with the actual raw files and reopen this if I have more issues. Thanks!
radioproektor commentedon Oct 12, 2026
You use too confused workflow. Transform from linear raw to tiff by Apple converter which converts gamma and color space and sets Lut-based icc profile is very bad starting point for negatives.
Same time using RAW directly in NegPy which ignore input profile is also bad idea, because colors always will be wrong. You need custom made ICC profile and Crosstalk correction for this. Currently both tools are not ready or not comfortable:
TIFF/RAW ICC/Matrix profile ignored.
There are no sliders to set Input matrix manually.
Crosstalk correction applied before all corrections and hidden somewhere deep inside, so it is impossible to interactively adjust it manually.
radioproektor commentedon Oct 12, 2026
Here is one more experiment. Instead of assign P3 gamma1.0 profile (which was incorrect), i converted from Apple Wide Color Sharing Profile to P3 gamma1.0 and processed as usual. Tonality behave predictable and colors are more-less OK. Markers show wherw i pick black point for film base Levels and gray point for R/B gamma adjustment.


jakegriffey commentedon Oct 13, 2026
Tried it again with RAW files and with JPGs. Sometimes the JPGs work but sometimes not. I've found more success with using the RAWs and cropping/rotating in Negpy. Works like it used to and I get results I'm happy with. So this was just user error 👍. Thanks for the help!