Opening 16-bit tiffs appear too white (not so with 8-bit tiffs)

[Paul Matthijsse]

Hello Alberto, I noticed a strange thing today.

I make a scan of a negative with X-Sane, open it in Gimp, convert it from 8-bit to 16-bit, make the image positive, apply the levels tool and save it as 16-bit tiff.

This image looks fine in Gimp, gThumb and Geeqie. See attachment 16-bit.scan.in.gimp.jpg.

Now I open it in Art for further editing, but it is way too light! See 16-bit.scan.in.art.jpg.

Once downsampled in Gimp to a 8-bit tiff, it opens fine in art, see 8-bit.scan.in.art.

I downsized the scan to 1600px wide, and it shows the same behaviour, see attached jojo_Br_3200ppi.16bit__rot90_positive_levels.in.gimp.1600px.tif and the arp file with the same name.

Am I doing something wrong here?

[Paul Matthijsse]

Hmm, I can’t upload tiffs here?

[agriggio]

For some reason, the image is interpreted as a raw file. I think it’s related to some recent changes done to support some ancient raw files from Kodak digital backs that have tif extension. I need to think about how to solve this properly, thanks for reporting!

[agriggio]

Ok, the problem is that this tif is a greyscale image. Try converting it to RGB in GIMP and ART should work properly

[Paul Matthijsse]

Hello, you’re right, it opens fine now! I noticed before when opening the grayscale that it said “RCD demosaicing”, which is strange for a tiff. I hope you can solve this rgb/grayscale issue.

Thanks, Paul.

[agriggio]

Commit 880cd7bffab4c9dd5c1408f83659367d9aa89b7f should have fixed this, hopefully without side effects

[Paul Matthijsse]

Hi, one side effect detected: error loading 16-bit tiff…

‌

[agriggio]

did it work before? Where is the file?

[Paul Matthijsse]

Yes before they opened, though washed-out.

It seems that Bitbucket does not accept tiffs. So get it from here (a downsampled version, 4,5MB).

https://bozart.eu/img/16bit.tif

‌

[agriggio]

works fine here… can you give more details of the version you are using?

[Paul Matthijsse]

Sure.

Version: 1.7.1-32-g880cd7bff
Branch: master
Commit: 880cd7bff
Commit date: 2021-01-12
Compiler: cc 7.5.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.22.2
Lensfun: V0.3.2.0
Exiv2: V0.25
LCMS2: V
Build type: Release
Build flags: -std=c++11 -march=native -Werror=unused-label -fno-math-errno -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags: -ltcmalloc -march=native
OpenMP support: ON
MMAP support: ON
Build OS: Linux
Build date: 2021-01-13T08:46:52Z

[agriggio]

Can you try setting WITH_MYFILE_MMAP:BOOL=OFF in your CMakeCache.txt? Thanks!

[Paul Matthijsse]

Hi Alberto, I did that and recompiled, same result (error loading…). But now I start to think that this particular scan is corrupted in one or other way, investigating that now (after lunch, that is). (And yes I know how to scan negatives, been doing that for over 20 years…). I’ll come back later.

[Paul Matthijsse]

Hello, I made a new scan of the same negative, made it 16-bit in Gimp and saved as tiff. This one opens fine in Art. So this whole story can be closed, I apologize for having bothered you.

But yesterday’s offending file still says “Encoding” when I try to open it in Art (just before the error msg appears), instead of “Loading tiff file”. So this one is perhaps still considered a raw file, as was your first thought.

Anyway, those stupid computers…

PS. I Art

‌

[Paul Matthijsse]

Hello Alberto, you can close this ticket. I upgraded my system from Xubuntu 18.04 to 20.04 and the problem seems to have gone.

Regards, Paul.