| Summary: | DNG don't get filtered as raw (group of items relevant) | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | AT <andreas> |
| Component: | Albums-Filters | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | caulier.gilles, dom1.nerriec, mail, mnaugendre |
| Priority: | NOR | ||
| Version: | 5.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.14.0 | |
| Sentry Crash Report: | |||
| Attachments: | screenshots | ||
|
Description
AT
2011-11-11 21:52:41 UTC
nb: I'm actually using kubuntu, but it wasn't on the drop down list, Phillips ppa. 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 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. 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. 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. 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. 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. Confirmation with a recent version is needed, see previous post. Created attachment 79938 [details]
screenshots
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.
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. 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. New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ? 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 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. :-)) 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. Oh, yeah, forgot: still digikam 4.12.0 with kde 4.14.12 >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
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. @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. 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. 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! 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! |