Bug 286373 - DNG don't get filtered as raw (group of items relevant)
Summary: DNG don't get filtered as raw (group of items relevant)
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: Albums-Filters (show other bugs)
Version: 5.3.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-11 21:52 UTC by AT
Modified: 2019-05-23 04:33 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.14.0


Attachments
screenshots (920.00 KB, application/x-tar)
2013-05-17 16:23 UTC, nerriec
Details

Note You need to log in before you can comment on or make changes to this bug.
Description AT 2011-11-11 21:52:41 UTC
Version:           2.3.0 (using KDE 4.7.3) 
OS:                Linux

If I filter image view by mime type filter --> no raw files (names translated back from german, so actual english name might differ), it sometimes doesn't filter out the dng images as raw, and they show up together with the jpg and png, which risks deleting them as duplicate images, besides being an irritant.
They still are proper raw, gimp alone can't handle them, ufraw does, but for some reason digikams mime filter interprets them as non-raw.
The other way round, if I filter for --> show dng, those pictures don't show up.

I'm not sure how to reproduce this problem, I think it happens after renaming, but it always only affects a number of random dng, never all. 
It's been happening to me at least since DC 1.9.

I thought I had reported the bug before, but can't find it in the bug tracker.

Reproducible: Sometimes

Steps to Reproduce:
Not sure, I think (batch) renaming plays a role, but can't confirm at moment.

Actual Results:  
dng images show even filter is set not to show raw images

Expected Results:  
dng images not to show.
Comment 1 AT 2011-11-11 21:53:37 UTC
nb: I'm actually using kubuntu, but it wasn't on the drop down list, Phillips ppa.
Comment 2 caulier.gilles 2011-11-11 22:07:26 UTC
Do you use versionning over your DNG ? For ex, do you open DNG to editor and convert it as JPEG, as new version ?

Gilles Caulier
Comment 3 AT 2011-11-11 22:35:40 UTC
No, I don't. I only use digikam for tagging, commenting, geotagging, renaming, ..., basically for organizing. 
For actual image manipulation I use ufraw for raw and gimp for everything else. For batch changing file format or image sizes I tend to use ImageMagick.
I usually have the dng associated either with jpg (from the cameras dual mode raw+jpg) or png if I processed the raws with ufraw and gimp.

Andreas.
Comment 4 mnaugendre 2011-12-23 10:20:58 UTC
I have the same problem with .CR2 files. There seems to be no special pattern. From one precise moment, some .CR2 pictures ceased to be recognized as RAW, and are listed as if they were JPEG files.
Some of these photos are renamed in Digikam, but I don't think it is always the case.

My picture are generally derawtised in another program (Rawtherapee in the past, Darktable more recently).

The new grouping function seems to complicate the issue, as it doesn't seem to identify RAW pictures properly, and they are not displayed in any group.
Comment 5 AT 2011-12-25 16:34:10 UTC
Had the problem with a bunch of dng again: after batch-renaming 172 images (86 dng and 86 jpg) 13 of the dng won't be recognized as raw anymore.
Under image properties, type is ADOBE-DNG, dimensions and colour mode unknown, depth of colour 0bpp. Dimension values displayed under the image is 0x0 (0.00 Mpx), with a size of 16.2 MiB.
Restarting digikam doesn't change things, nor does F5.
Other programs like geeqie still recognize dimensions.

What did solve the problem here (as a workaround), is re-reading the metadata, after that the image dimensions were recognized and the image correctly identified as dng and raw.
Comment 6 Marcel Wiesweg 2011-12-26 21:49:55 UTC
This scenario looks as if the file properties from the filesystem are read correctly, but not the metadata. One could think that the renaming happens in between, but I'm not sure why a file would be rescanned before the rename. In case it happens though, we'd need to take precautions.
Comment 7 Marcel Wiesweg 2012-02-20 11:40:57 UTC
In 2.4.0 we have replaced the file monitoring code, now files will be rescanned after they have been closed for writing.
Is someone still able to reproduce this problem after batch renaming with 2.5.0? Then I'd like to investigate further.
Comment 8 Marcel Wiesweg 2013-03-21 19:49:04 UTC
Confirmation with a recent version is needed, see previous post.
Comment 9 nerriec 2013-05-17 16:23:11 UTC
Created attachment 79938 [details]
screenshots
Comment 10 nerriec 2013-05-17 16:47:08 UTC
Hi,

I use 2.6.0 on Linux Debian, and have the same problem.
608 JPEG and 98 DNG in an album.
I renamed all the files using Digikam. I included the "e" option, example : 
###[e,652,1]_[file]

I attached a tar file ("screenshots") to illustrate these steps :

Step 1
Two filters : text = "dng",  and MIME type = "not RAW"
See 286373_01_filter.png

Step 2 
286373_02_bad_images.png
We see that some images are shown, and we see that "image properties" for the selected image are empty, exactly as in AT's post dated 2011-12-25 16:34:10 UTC

286373_03_exif_good.png  : we see that EXIF data has not the same problem as "image properties".

Step 3.
I execute a "touch 495_IMCD5963.jpg" in a shell, to force digikam to re-read datas from the file.
After that, I have to select "all files" in MIME filter to see again the file (it is the expected behaviour), and the images properties are correctly displayed :
286373_04_after_touch_without_filter.png


Note that the problem is NOT specific to DNG files. I have the same problem for 29 JPEG files.
I used digikam editor for some JPEG, but surely not for the 29 files.

I checked quickly the 29 files, and I am quite sure that I didn't perform any specific action on these files.

I hope it can help.
Thanks in advance.
Comment 11 AT 2014-12-24 17:46:22 UTC
Just had the problem again, some dng are not recognized after batch renaming dng + associated jpg/ png.
Re-reading the exif info of the dng lets digikam recognize them again.

digikam 4.4.0 and sabayon linux.
Comment 12 AT 2014-12-24 17:48:42 UTC
Oh, and kde 4.14.3,

and as before, it's not all dng, only the odd one in between, without any obvious pattern to me.
Comment 13 caulier.gilles 2015-06-25 08:56:09 UTC
New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?
Comment 14 caulier.gilles 2015-08-17 11:26:13 UTC
digiKam 4.12.0 is out :

https://www.digikam.org/node/741

We need a fresh feedback using this release please...
Thanks in advance.

Gilles Caulier
Comment 15 AT 2015-10-08 15:46:51 UTC
Hi there,

sorry for the long delay. First the Sabayon repos didn't catch up with digikam versions, and then I didn't have a suitable large No of photos ready. ;-)
I've renamed a few hundred dng/ jpg or png pairings now, and it seems it's resolved with digikam 4.12.0.
Thumbs up. :-))
Comment 16 AT 2016-01-02 22:14:34 UTC
Hi there,

it seems my comment from above was premature.
After renaming about 600 images, some of them multiple times, I had about 3 dng that were falsely filtered as not raw. As before, reloading the metadata solved the problem and they are recognized as raw again.
Comment 17 AT 2016-01-02 22:16:09 UTC
Oh, yeah, forgot: still digikam 4.12.0 with kde 4.14.12
Comment 18 caulier.gilles 2016-01-03 10:42:16 UTC
>As before, reloading the metadata solved the problem and they are recognized as raw >again.

So this is a registration problem with DNG using older digiKam release, which is solved to updating database info as well.

Gilles Caulier
Comment 19 AT 2016-12-18 17:31:10 UTC
I have the same problem again/ still with digikam 5.3 on Sabayon using the gentoo ebuild, though it feels like it is happening less frequently.
After batch-renaming a bunch of imades dgn is not recognized as raw until I re-read the metadata.

Can't test with 5.4 appimage, stopped running after a crash with segfault.
Comment 20 Julian Steinmann 2019-04-21 19:46:06 UTC
@AT: could you test this again (using the Digikam 6.0.0)? A lot of bugs were fixed since then, and it's easily possible that your problem was also resolved.
Comment 21 AT 2019-04-23 22:31:58 UTC
Will try as soon as I can but not sure when that will be. Unfortunately, between work and toddler I'm hardly getting around to do anything with my images.
Comment 22 Bug Janitor Service 2019-05-08 04:33:07 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 23 Bug Janitor Service 2019-05-23 04:33:08 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!