I never used GIMP, buy I can try
I’ve re-read the description, and maybe it is something else:
The screenshot from Susana shows 16-bit TIFF output, which should be OK, if the problem was related to the bug:
But then I don’t know how to interpret TIFF RGB 300 or 100 (which are bad), when TIFF Adobe RGB 100 and TIFF sRGB100 is almost the same as the JPG sRGB 100 (I assume that’s 100 DPI).
Anyway, until we get answers and input image (raw or whatever) + sidecar, it’s just guesswork, and we have guessed enough, I think.
There are 4 images:
JPG sRGB 100: 2˙952x1˙969 px, using darktable’s built-in sRGB profile
TIFF Adobe RGB 100: 3˙897x2˙599 px, using Adobe RGB (compatible) profileTIFF sRGB 100: 3˙897x2˙599 px, using darktable’s built-in sRGB profile
TIFF Adobe RGB 300: 11˙689x7˙796 px, using Adobe RGB (compatible) profile
The first one, JPG sRGB 100, is more contrasty than all the others, but is also smaller. Also, its processing stack is different, containing 27 steps. Therefore, it is only logical that it looks different, too.
The middle 2, TIFF Adobe RGB 100 and TIFF sRGB 100 look quite close; I can see some difference on my wider-than-sRGB display, but that is expected. They are also the same size in pixels. Only one of them, TIFF Adobe RGB 100, has a processing stack, one with 38 steps. I think it is safe to assume both used the same stack; the colour differences can be attributed to colour management (Adobe RGB can represent more saturated colours than sRGB).
The last one, TIFF Adobe RGB 300, uses the same stack as TIFF Adobe RGB 100, but was exported with upscaling. It looks much less contrasty.
So:
- the images are of different sizes → unless all were exported with high-quality rescaling, this could have lead to differences
- one image has a different stack → this surely leads to a difference
- one of those images is heavily upscaled → there’s a recently fixed issue related to upscaling (though it should not be affected, since, according to the screenshot, high-quality resampling was turned on).
The extracted XMP sidecars, including history stack, where available (exiv2 -e X ex *tif *jpg):
JPG sRGB 100.xmp (19.7 KB)
TIFF Adobe RGB 100.xmp (35.6 KB)
TIFF Adobe RGB 300.xmp (35.6 KB)
TIFF sRGB 100.xmp (2.3 KB)
My big question is that I will make an assembly with Photoshop to print 100 cms x 66 cms (3*2).
For this, I should export TIFF AdobeRGB 300 to continue editing with Photoshop and print, correct?
But that TIFF does not look simlar with the real edition in Darktable. The edition in Darktable is the same as the JPG sRGB 100
@susanag :
- your
JPG sRGB 100was created using settings different from those used forTIFF AdobeRGB 300, so of course the output is also different. The output image is also a different size in pixels, even when comparing to the other ‘100 DPI’ images. - there was a known bug with upscaling, which has been fixed. You may want to try one of the development builds.
- upscaling makes very little sense, as you are not ‘adding more data’ to the image, you merely ‘inflate’ and smear the existing pixels.
I can try an export at various sizes if you provide the input file (I assume it is a raw), and one or more XMP sidecars you would like me to test with.
2 Likes
The 300 ppp is only needed if that print should be watched from ~30 cm.
If the intended viewing distance is 1m, 100ppp should be enough.
For a normal print of that size, viewing distance would be closer to 1.5-2m, so even 75ppp would be enough.
The 100ppp jpeg you showed us is 2952×1969 pixels. At 100 ppp, that should give you an image width of 29.52 inches or ~75 cm. As indicated above, that file would have enough pixels for a good quality print of 1m (or basically any other size!). If the image is to be part of an assembly, the final printed resolution of this part could be even higher than estimated here.
@Kofa already has explained where there are issues with the different versions you want to compare.
Using the current development version, I’ve exported at various sizes:
- 0 x 0 px (so original size)
- 2048 x 2048
- 12000 x 12000
In 8-bit JPG and 16-bit TIFF, in sRGB and Adobe RGB. All of them look pretty much the same as the darkroom:
I used the sidecar you provided:
The exported results are here:
https://drive.google.com/drive/folders/1MYTthg-Y_Iv7RJ1NXA6NUmt6cwvMwjd5
I only varied the highlighted items:
Maybe download the exported files (or some of them), and check if they look (nearly) the same on your computer.
I’ve re-downloaded your files. Here they are, side-by-side with the darktable view.
The JPG, which we know was processed with different settings (see my analysis above) is more contrasty:
These two are quite close to each-other:
The upscaled one has low contrast:
1 Like
I’ll try to test with 4.6.1 and 4.8.1, but cannot promise to do it before the weekend.
1 Like
Thank you very much! I will see everything .
Cannot reproduce. darktable 4.8.1 side-by-side with upscaled TIFF Adobe RGB output (the others look very similar):
Update: I exported 8-bit TIFF by accident. That is what I have uploaded. But the ones with the development version, as well as the files I exported using 4.6.1 (see next post) were 16-bit images, and I don’t see a difference.
I’ve uploaded the exported files to Google drive (same link as before), check the folder darktable-4.8.1. I varied the format (JPG vs TIFF), high-quality resampling enabled / disabled ( hq or lq in the name), and the colour space (srgb vs argb in the name).
I did not use the DPI setting, but the pixel size. No time for more today.
1 Like
And a direct comparison with your export (comparing to my previous post where I compared your upscaled export with darktable, and it clearly showed the problem you have, with the upscaled file being ‘pale’):
Left: my upscaled export; middle: yours; right: darktable.
1 Like
OK, so I have built darktable 4.6.1, and used your export settings. Your Spanish screenshot on the left, my English screenshot on the right; I think the settings are identical:
The file sizes are already different between your export and mine:
And yours is pale. Mine isn’t. Here is my export in Geeqie (left), side-by-side with yours in Gimp (right).
This was done using your version of darktable, 4.6.1, using your XMP sidecar file and your export settings. I’m afraid there’s nothing more I can do.
You could try with a clean config directory, and/or upgrade to a newer version of darktable (even though the version does not seem to make a difference).
1 Like
I updated the Darktable new version to see if I can solve that differences.
Thank you very much.
@kofa Nice follow up!
Random thought: I wonder if this has to do with a bug of a dependency that @susanag has or the installation package itself.
@susanag, could you please share how you installed dt? I.e., where you got it from.
NB.: This might not be a great indicator of a more fundamental difference, as different dt binaries on different OSes might be using different libtiff, which again might be using zlib vs libdeflate, so you end up w/ slightly different compression even if the settings are the same…
1 Like
I did it from the oficial website https://www.darktable.org/
“NB.: This might not be a great indicator of a more fundamental difference, as different dt binaries on different OSes might be using different libtiff, which again might be using zlib vs libdeflate, so you end up w/ slightly different compression even if the settings are the same…”
Thank you very much for all your explanation; those terms are too specific for my knowledge.
That last comment was a reminder to me, not to draw conclusions based on file size. Nothing you have to worry about.
I also did the visual comparison, and that’s the important bit.
May I ask, what operating system you use? Are you on a Mac, or do you use Windows?