darktable
darktable copied to clipboard
Fix issue introduced by 7dc0faf by doing more cleanup in gboolean vs …
…int.
Fixes #17536
@wpferguson : Can you double check this. TIA.
I saw this last night, but didn't realize that it was my change that caused it. When I went to find the problem, I couldn't reproduce. Testing now....
I still see it on tif, dng, and a cr3. I'll do some digging....
Another datapoint, opened a skull image in darkroom and it's fine, but the filmstrip thumbnails are all skulls
I backed up before my change and loaded some tif's with -d imageio -d cache
Here's part of the log...
7.1830 [tiff_open] 3089x2048 8bpp, 3 samples per pixel.
7.1888 [tiff_open] 3089x2048 8bpp, 3 samples per pixel.
7.1892 [tiff_open] 3089x2048 8bpp, 3 samples per pixel.
7.1898 [tiff_open] 2545x3393 16bpp, 3 samples per pixel.
7.1902 [tiff_open] 1729x1729 16bpp, 3 samples per pixel.
7.1906 [tiff_open] 4816x3219 16bpp, 4 samples per pixel.
7.2731 [dt_imageio_export_with_flags] modules: colorin colorout gamma
7.2731 [dt_imageio_export] thumbnail imgid 38474, 3089x2048 --> 1357x900 (scale=0.4395, maxscale=1.0000). upscale=no, hq=no
7.2785 [dt_imageio_export_with_flags] modules: colorin colorout gamma
7.2786 [dt_imageio_export] thumbnail imgid 38475, 3089x2048 --> 1357x900 (scale=0.4395, maxscale=1.0000). upscale=no, hq=no
7.3014 [dt_imageio_export_with_flags] modules: colorin colorout gamma
7.3014 [dt_imageio_export] thumbnail imgid 38476, 3089x2048 --> 1357x900 (scale=0.4395, maxscale=1.0000). upscale=no, hq=no
7.3149 [dt_imageio_export_with_flags] modules: colorin colorout gamma
7.3149 [dt_imageio_export] thumbnail imgid 38477, 2545x3393 --> 675x900 (scale=0.2653, maxscale=1.0000). upscale=no, hq=no
7.3184 [mipmap_cache] generate mip 3 for ID=38474 from scratch
7.3191 [tiff_open] 4816x3219 8bpp, 4 samples per pixel.
7.3322 [mipmap_cache] generate mip 3 for ID=38475 from scratch
7.3340 [tiff_open] 2550x3300 8bpp, 3 samples per pixel.
7.3431 [mipmap_cache] generate mip 3 for ID=38476 from scratch
trying to trace the execution to see how we get from tiff open to dt_imageio_export
The problem seems to be in dt_imageio_large_thumbnail but I haven't figured out what it is or how to solve it.
Unless you have an idea, I would say revert my PR and I'll work on it until I solve the problems. At least that way it wont affect people trying to use master.
For me the fix works, at least for NEF and DNG
@AndDiSa : Indeed, it works for RAW & JPEG but still buggy for TIFF.
@wpferguson : I have pushed the revert I had prepared.
After a nights sleep and some time to think this is what I came up with.
The original problem was that dt_imageio_export_with_flags is a gboolean returning "backwards" indicators. dt_imageio_export_with_flags used to return an int, 0 for success and 1 for error which is standard. Nothing downstream uses dt_imageio_export_with_flags as a boolean and all the downstream code still treats it as returning an int.
So, I propose simply turning dt_imageio_export_with_flags back into an int and let it return 0 and 1. The sanity crowd is happy because the return value is standard, and almost no code needs to be changed (I'll look at the Lua stuff).
As for dt_imageio_large_thumbnail I'm still going to play with this and see if I can at least understand the coupling between it and the mipmap_cache code. I'm starting to suspect that the real issue may be the mipmap_cache not asking (or not asking correctly) for the thumbnail.
Thanks for cleaning up my mess.
@wpferguson : No problem, I spend quite some time trying to fix the issue but could not either... One data point:
In dt_imageio_large_thumbnail we have (in this PR):
gboolean dt_imageio_large_thumbnail(const char *filename,
uint8_t **buffer,
int32_t *width,
int32_t *height,
dt_colorspaces_color_profile_type_t *color_space)
{
int res = TRUE;
So res to TRUE, and some early return:
// get the biggest thumb from exif
if(dt_exif_get_thumbnail(filename, &buf, &bufsize, &mime_type))
goto error;
But the goto error here is misleading, a whole mess :( This is not an error as we exit with 1 (TRUE) !!!
I tried fixing that but the last state of this PR is ok for everything expect TIFF.
I would say that we want to continue to work on this... We need to fix for a better future :)
Maybe I should change my username to Pandora :-D
I would say that we want to continue to work on this... We need to fix for a better future :)
I agree. My brain segfaulted a few times trying to make sense of the code. I'll keep playing with it. I enjoy puzzles
Good, start over this PR which has already quite some fixes.
@wpferguson : I have just pushed a new version with your changes and mine on top. Let's play :)