[digikam] [Bug 385443] 'Auto toggle parents' unnatural behavior when removing a tag
https://bugs.kde.org/show_bug.cgi?id=385443 --- Comment #5 from Sebas --- (In reply to caulier.gilles from comment #4) > @sebas, > > digiKam 8.0.0 is out. This entry still valid with this release ? > > Best regards > > Gilles Caulier Hey, Yes this still applies. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 393313] Next-function sometimes goes next image, other times it scrolls the bar
https://bugs.kde.org/show_bug.cgi?id=393313 --- Comment #8 from Sebas --- Hello Gilles, It's been a while... Hope you are well. It seems to still be there to a certain extent, but it feels a lot faster/snappier than I remember. Good progress. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385443] 'Auto toggle parents' unnatural behavior when removing a tag
https://bugs.kde.org/show_bug.cgi?id=385443 --- Comment #2 from Sebas --- This still applies. It is unnatural. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 393313] Next-function sometimes goes next image, other times it scrolls the bar
https://bugs.kde.org/show_bug.cgi?id=393313 --- Comment #4 from Sebas --- This issue is about smart caching. Preloading the next x images from the current one to eliminate loading time. Is Digikam changed on this aspect? It feels a bit better now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 399596] Tag tree keeps reverting back to incorrect format after re-adding collection
https://bugs.kde.org/show_bug.cgi?id=399596 --- Comment #12 from Sebas --- For me there is no easy way to test if this issue still applies. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406979] Specific PNG crashes Digikam
https://bugs.kde.org/show_bug.cgi?id=406979 --- Comment #10 from Sebas --- No crash in 7.0.0. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382706] Assigning tag to NEF-file results in crash + config disappearing
https://bugs.kde.org/show_bug.cgi?id=382706 --- Comment #10 from Sebas --- Played around a bit: adding, editing, removing. No issue happened. We could assume this issue is resolved, until it happens again. For me however, I am not planning to use tags on NEF-files. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382706] Assigning tag to NEF-file results in crash + config disappearing
https://bugs.kde.org/show_bug.cgi?id=382706 --- Comment #9 from Sebas --- Hello, sorry for the time away. I will assign some time to play around with this. Update soon. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 380876] Tags in Digikam DB maintained after being removed from file and file re-scanned
https://bugs.kde.org/show_bug.cgi?id=380876 --- Comment #19 from Sebas --- Understood. So if I want to only write to sidecar for unsupported files I should enable: [X] Write to sidecar files: Write to XMP sidecar for read-only item only And to later read from it, I guess also: [X] Read from sidecar files -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406979] Specific PNG crashes Digikam
https://bugs.kde.org/show_bug.cgi?id=406979 --- Comment #8 from Sebas --- Hmm weird. Image displays well here in Windows Photo Viewer and is editable in Paint.NET. Broken in IrfanView. So this must be corruption...which is worrying... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406979] Specific PNG crashes Digikam
https://bugs.kde.org/show_bug.cgi?id=406979 --- Comment #4 from Sebas --- Done. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 380876] Tags in Digikam DB maintained after being removed from file and file re-scanned
https://bugs.kde.org/show_bug.cgi?id=380876 --- Comment #17 from Sebas --- I removed tags from MOV-files in Digikam, then removed the tags from database. Then, after starting with a new database due to the PNG-bug, the MOV-files came back with the tags attached ánd enabled again. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406981] GoPro video thumbnails are just noise
https://bugs.kde.org/show_bug.cgi?id=406981 --- Comment #3 from Sebas --- By the way... this problem starts from around the filesize of the provided sample. Smaller files do not suffer, and large files that have been trimmed (causing a new file) by use of Quicktime on OSX also do not suffer. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406981] GoPro video thumbnails are just noise
https://bugs.kde.org/show_bug.cgi?id=406981 --- Comment #2 from Sebas --- Here is one: https://www.dropbox.com/s/8of0uzwmp8hh4v1/GOPR6539.MP4?dl=0 Will remove after a few days. digikam version 6.1.0 CPU cores: 16 Eigen: 3.3.7 Exiv2: 0.27.0 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes ImageMagick codecs support: No KF5: 5.56.0 LensFun: 0.3.95-0 LibCImg: 130 LibJPEG: 90 LibJasper: 2.0.16 LibLCMS: 2090 LibLqr support: No LibPGF: 7.19.03 LibPNG: 1.6.36 LibRaw: 0.19.2 LibTIFF: 4.0.10 Marble: 0.27.20 Parallelized demosaicing: No Qt: 5.12.2 Qt Webkit support: Yes VKontakte support: No AkonadiContact support: No Baloo support: No Calendar support: Yes DBus support: No Database backend: QSQLITE HTML Gallery support: Yes LibAVCodec: 58.35.100 LibAVFormat: 58.20.100 LibAVUtil: 56.22.100 LibGphoto2 support: No LibOpenCV: 3.4.5 LibQtAV: 1.12.1 Media player support: Yes Panorama support: Yes -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406979] Specific PNG crashes Digikam
https://bugs.kde.org/show_bug.cgi?id=406979 --- Comment #2 from Sebas --- I can mail it to you. Don't wish to put this one up in public. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398126] Group feature works across albums (undesired behaviour?)
https://bugs.kde.org/show_bug.cgi?id=398126 --- Comment #2 from Sebas --- Kick. I would like to group all JPGs and NEFs in albums, but (correct me if I am wrong) there is no easy way to do this except for doing it to every individual album. I suggest a global option to enable automatic grouping for albums. Further details: My collection tree is like: 2019a Holiday in country X\2019-01-20a Roadtrip Y\DSC_1234.JPG 2019a Holiday in country X\2019-01-20a Roadtrip Y\DSC_1234.NEF Therefore, last time when I tried, selecting multiple albums and creating a group results in cross-album groups. No justification for that, right? So that makes this functionality pretty useless. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406981] New: GoPro video thumbnails are just noise
https://bugs.kde.org/show_bug.cgi?id=406981 Bug ID: 406981 Summary: GoPro video thumbnails are just noise Product: digikam Version: 6.1.0 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Thumbs-Video Assignee: digikam-bugs-n...@kde.org Reporter: djse...@home.nl Target Milestone: --- Digikam 6.0/6.1 GoPro video (MP4) thumbnails appear as coloured snow / noise. Model used: GoPro 4 Black Edition with latest firmware. Besides not being able to recognize what the video is about...another downside for me is that when I do my (just started with this) 4 monthly check for photo/video corruption by actually looking at the thumbs (which I guess I then have to regenerate every 4 months), I cannot see if the video is corrupted or not, plus obviously it delays the checking process because having to verify the noise is a GoPro video and not a really damaged file. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406979] New: Specific PNG crashes Digikam
https://bugs.kde.org/show_bug.cgi?id=406979 Bug ID: 406979 Summary: Specific PNG crashes Digikam Product: digikam Version: 6.1.0 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: crash Priority: NOR Component: Database-Thumbs Assignee: digikam-bugs-n...@kde.org Reporter: djse...@home.nl Target Milestone: --- Digikam 6.0 and 6.1. A specific PNG file crashes the whole application. I think it happens when Digikam tries to generate a thumbnail. I moved the file out of the collection and now it seems fine. Although, knowing Digikam's stability for me...it is just waiting for the next crash and database corruption. *sigh* I can provide the file to a developer. Just asking you to delete it afterwards because there is a person in the picture (not me). Let me know how to get it to you. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 380876] Tags in Digikam DB maintained after being removed from file and file re-scanned
https://bugs.kde.org/show_bug.cgi?id=380876 Sebas changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #15 from Sebas --- Still happened in 6.0 for MOV-files. No results for other filetypes. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 399596] Tag tree keeps reverting back to incorrect format after re-adding collection
https://bugs.kde.org/show_bug.cgi?id=399596 --- Comment #7 from Sebas --- Seems like I forgot to answer to Maik Qualmann's last reply. I did fix the issue manually so it is a bit hard for me to recall the whole thing, but let's try. Digikam saves individually in image metadata (if enabled) these things: 1. Tags 2. Tagtree I removed some tags and added new ones, or maybe renamed something. Then, after rescanning (because of some 'Collection disappearing if network share unavailable' bug) the old tagtree keeps appearing again and again. What I found when opening these images in a text editor is that when removing tags, Digikam does not (always?) also remove that tagtree from custom metadata. It should do so when the tagtree ceases to exist. Maybe a check for this is not coded. Steve Franks, I am not sure it is exactly the same problem. I don't know how Digikam will try to build a tagtree from tags set by other programs. Obviously those programs will not save the tagtree to custom metadata as Digikam does and if they save the tagtree to metadata at all, I have no idea if Digikam can read other tagtree metadata than its own. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382706] Assigning tag to NEF-file results in crash + config disappearing
https://bugs.kde.org/show_bug.cgi?id=382706 --- Comment #5 from Sebas --- Is there a supposed fix? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 399596] Tag tree keeps reverting back to incorrect format after re-adding collection
https://bugs.kde.org/show_bug.cgi?id=399596 --- Comment #4 from Sebas --- Using 6.x now. I opened a photo in Notepad++ and found some interesting things. Apparently Digikam saves tag trees in images apart from the tags themselves. The latter ones can not be read by software like Windows Explorer or IrfanView. Digikam tag trees are saved in custom metadata fields. The strange thing is though...if I have moved all those images out of the wrong tree, why is this wrong tree still present in the custom metadata fields. It should have been cleared out. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 399596] Tag tree keeps reverting back to incorrect format after re-adding collection
https://bugs.kde.org/show_bug.cgi?id=399596 --- Comment #3 from Sebas --- Database maintenance on the tags with option 'sync metadata and database' -> 'from image metadata to database' actually made it worse. The wrong tag tree was restored and probably all images with those tags are shown there and in the good tag tree. Digikam mostly shows the tags duplicated below the images while Windows Explorer doesn't show they are duplicated in the metadata. Might try 6.x soon. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 399596] Tag tree keeps reverting back to incorrect format after re-adding collection
https://bugs.kde.org/show_bug.cgi?id=399596 --- Comment #2 from Sebas --- After clearing all tags from the wrong tag tree from the images and applying tags from the right tree format it seems to go good with the images, but... the tag tree format from the example keeps coming back. Empty of course. I did not try database maintenance by the way. Will do that and report back. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 399596] New: Tag tree keeps reverting back to incorrect format after re-adding collection
https://bugs.kde.org/show_bug.cgi?id=399596
Bug ID: 399596
Summary: Tag tree keeps reverting back to incorrect format
after re-adding collection
Product: digikam
Version: 5.9.0
Platform: MS Windows
OS: MS Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Tags-Engine
Assignee: digikam-bugs-n...@kde.org
Reporter: djse...@home.nl
Target Milestone: ---
With https://bugs.kde.org/show_bug.cgi?id=399594 happening much lately, it
caught my eye that the tag tree is being reverted to an already corrected
format.
Example to make it clear:
Tree:
Cars
--Brand 1
Model A
Model B
--Brand 2
Model A
--Brand 3
Model A
People
--Person 2
--Person 4
People
--Person 1
--Person 2
--Person 3
--Person 4
--Person 5
--Person 6
See above how all of a sudden the people subtree and some of the persons are
(duplicated) inside a car brand. I have no idea how that happened in the first
place. There were also pictures in the end points of that wrong tagtrees, but
not as much as in the correct tag tree. So I untagged those pictures and added
the right tags to them. After that I deleted the wrong tag tree ('People'
inside car 'brand 3.')
The collection gets rescanned, and voila, the tree as shown above is present
again, just without pictures in the wrong parts.
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 399594] New: Collection being thrown away again and again
https://bugs.kde.org/show_bug.cgi?id=399594 Bug ID: 399594 Summary: Collection being thrown away again and again Product: digikam Version: 5.9.0 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Database-Files Assignee: digikam-bugs-n...@kde.org Reporter: djse...@home.nl Target Milestone: --- https://forum.kde.org/viewtopic.php?f=255=153810 When restarting the SMB (samba) service on the (linux) server, the network share holding the pictures is unavailable for a few seconds. Digikam (on Windows) immediately removes the tree from collection. I have looked through the options/preferences and did not find an option to prevent this behaviour. The share is added as 'Network Share.' BUT, even more, several times lately the collection disappeared while SMB (samba) was still running. I don't know why, but this behaviour of collections fully disappearing again and again is highly undesirable. Note the rescan time on 1Gbit/s for 2 items / 300 GB is 40-60 minutes. Requesting: Digikam not dropping the collection when unavailable. Instead display a status 'collection unavailable.' Especially when the root folder of a collection is unavailable Digikam should be smart enough to realize this is probably a reachability issue rather than the user moving or removing the full tree, otherwise the user would have also remove or readded the tree in Digikam settings. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398126] New: Group feature works across albums (undesired behaviour?)
https://bugs.kde.org/show_bug.cgi?id=398126 Bug ID: 398126 Summary: Group feature works across albums (undesired behaviour?) Product: digikam Version: 5.9.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Albums-Group Assignee: digikam-bugs-n...@kde.org Reporter: djse...@home.nl Target Milestone: --- It is almost certain in big collections there will be files with the same name. When selecting ALL photo's in database and doing RMB -> group -> group selected by filename, the result is that there will be cross-album groups. Although there might be situations where you want this, I think from the most natural point of view it is undesirable. Anyway, in case I am missing the good side of this, a solution does not have to replace this feature. The suggestion is to have an option for grouping of JPEG and RAW, but only on album (folder) level. It would be even more nice if this AUTOmatically happens instead of having to do it manually each time. Cheers! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382706] Assigning tag to NEF-file results in crash + config disappearing
https://bugs.kde.org/show_bug.cgi?id=382706 --- Comment #3 from Sebas --- I am not sure. With 5.9.0 I've been able to tag NEF's for months now without problems...until...yesterday. After tagging a crash occurred and after restarting a certain part of my tag tree had moved to some other part of the three. Today, I see the whole database is empty and 300GB is being rescanned now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 393313] Next-function sometimes goes next image, other times it scrolls the bar
https://bugs.kde.org/show_bug.cgi?id=393313 --- Comment #2 from Sebas <djse...@home.nl> --- >From thumbnails select preview. A bar shows up at top. I make the bar as minimal as possible for more overview and bigger main picture. Could this be made a preference? Then start moving right on PNG's of 60-140MB. And that seems to be the issue. When moving quickly there is quite a delay in displaying it in the main part of the window. And sometimes it gets stuck, then you have to move to another image and move back. Is there a setting to increase caching? Implement a loading indicator might be helpful too. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 393313] New: Next-function sometimes goes next image, other times it scrolls the bar
https://bugs.kde.org/show_bug.cgi?id=393313 Bug ID: 393313 Summary: Next-function sometimes goes next image, other times it scrolls the bar Product: digikam Version: 5.9.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Thumbs-BarView Assignee: digikam-bugs-n...@kde.org Reporter: djse...@home.nl Target Milestone: --- Pressing either the right arrow or space bar, or whatever other way to call for next image...sometimes you get next image, but after a while it only scrolls the horizontal bar, and no next image anymore. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 386910] New: Collection disappeared
https://bugs.kde.org/show_bug.cgi?id=386910 Bug ID: 386910 Summary: Collection disappeared Product: digikam Version: 5.7.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Database Assignee: digikam-bugs-n...@kde.org Reporter: djse...@home.nl Target Milestone: --- 2nd time with this version that everything is gone. Have no clue about why, didn't really do anything unusual in the program. Also no crash. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385443] New: 'Auto toggle parents' unnatural behavior when removing a tag
https://bugs.kde.org/show_bug.cgi?id=385443 Bug ID: 385443 Summary: 'Auto toggle parents' unnatural behavior when removing a tag Product: digikam Version: 5.7.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: minor Priority: NOR Component: Tags-Engine Assignee: digikam-bugs-n...@kde.org Reporter: djse...@home.nl Target Milestone: --- An auto toggle feature is being offered in Digikam tagging. Settings it to 'parents' makes Digikam behave like many other programs do. At least, that is for adding a tag. When removing a tag, it behaves very different as one would expect, especially compared to other programs: the whole tree is deleted. While technically this is inline with the description, a more natural way would be to only delete the chosen tag and its children. That's how most programs work. In other words, I am suggesting this possibility/setting: * When adding a tag, add that tag and its parents. * When removing a tag, remove that tag and its children. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384182] Combining JPEG and RAW in thumbs view
https://bugs.kde.org/show_bug.cgi?id=384182 Sebas <djse...@home.nl> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Sebas <djse...@home.nl> --- Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384182] Combining JPEG and RAW in thumbs view
https://bugs.kde.org/show_bug.cgi?id=384182 --- Comment #2 from Sebas <djse...@home.nl> --- That is what I was looking for. I had no idea it was behind that menu/description. Is there any way to turn this on by default for albums instead of having to group manually? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384182] New: Combining JPEG and RAW in thumbs view
https://bugs.kde.org/show_bug.cgi?id=384182 Bug ID: 384182 Summary: Combining JPEG and RAW in thumbs view Product: digikam Version: 5.7.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Albums-Group Assignee: digikam-bugs-n...@kde.org Reporter: djse...@home.nl Target Milestone: --- I've read most of https://bugs.kde.org/show_bug.cgi?id=126149 but this discussion is from quite a while back and marked as RESOLVED FIXED. Let's see where we are now. Recently I started to shoot in RAW, but I keep the JPEGs also. I saw that digiKam shows both thumbs, which is a bit annoying of course. My reasons for shooting both JPEG and RAW are: 1. When on holiday I shoot 120 photos per day average (which probably isn't even that much). I don't have time to process every RAW file to a fully developed nice looking picture. Only the best shots I process and export to TIFF/PNG/etc. While I still have all the RAWs, there probably comes a time where I will delete the RAWs I didn't process and keep the JPEGs for the photos that are nice but not awesome enough to process their RAWs. So, time wise I can't shoot RAW only. 2. Then you say: "But the RAW already contains the JPEG inside!" Yes that is true. digiKam proved this by showing the same image for the RAW preview compared to the JPEG. BUT: a) The quality of the in RAW embedded JPEG is lower than the standalone JPEG. b) While digiKam easily displays the embedded JPEG, other programs I use, like the Windows build in ones, they try to process the RAW instead of showing the embedded JPEG. And at trying to process, well, the often fail. Having an option to display only one thumb with option to indicate that a JPEG and RAW version are available would be nice. A solution could be to move the RAWs to their own tree, maybe even outside the album collection. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382706] Assigning tag to NEF-file results in crash + config disappearing
https://bugs.kde.org/show_bug.cgi?id=382706 --- Comment #1 from Sebas <djse...@home.nl> --- I see the tags were saved to the NEF, despite the crash. I removed half of the tags from the NEF's and again: crash. This time only the gui specific preferences were lost. In a third try, when the last tag data was removed from the NEF: no crash. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382707] New: Order of albums different between tree view and thumbnail view
https://bugs.kde.org/show_bug.cgi?id=382707 Bug ID: 382707 Summary: Order of albums different between tree view and thumbnail view Product: digikam Version: 5.7.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Thumbnails Assignee: digikam-de...@kde.org Reporter: djse...@home.nl Target Milestone: --- Having the album tree view on the left, this is the order: 2015\* 2016\* 2016 Bla\* (All those year folders contain subfolders by date, like 2016\2016-01-01 AlbumTitle and one root image 'folder.jpg') The thumbnail views orders like this: 2015\* 2016\folder.jpg 2016 Bla\* 2016\* Obviously the album tree view order is correct and the thumbnail view order is wrong. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382706] New: Assigning tag to NEF-file results in crash + config disappearing
https://bugs.kde.org/show_bug.cgi?id=382706 Bug ID: 382706 Summary: Assigning tag to NEF-file results in crash + config disappearing Product: digikam Version: 5.7.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: major Priority: NOR Component: Tags Assignee: digikam-de...@kde.org Reporter: djse...@home.nl Target Milestone: --- On accident I assigned a tag to a NEF-file. The result was digiKam crashing. After restarting, the 'first install' dialog appeared. Apparently the config file was corrupted/removed/overwritten. I was unable to find a file containing my old settings. Also no log of the crash, only a 42MB dump file. The digikam4.db, recognition.db and thumbnails-digikam.db appear to be in good shape, although I save tags to files anyways. Chosen severity major because damage is more than crash. This bug has not been reproduced. Please request, but first try yourself. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374356] "Show item in file explorer" as well as "open with"
https://bugs.kde.org/show_bug.cgi?id=374356 --- Comment #5 from Sebas <djse...@home.nl> --- In 5.7 (thanks for that) I see: - Album -> Open in File Manager - Item -> Open with Default Application Two nice features but just not close enough. What I am looking for (and I think wildcowboy too) is a feature to select an image inside a tree and then have a function to open the file manager to the location where the image is in the file system. Example: Tree: C:/2017/2017-01-15 Party/Received photo's/DSC_0001.jpg. What happens is, I open the 2017 album in the main window and then scroll down until I see 'the very interesting image' DSC_0001.jpg. Then I want to see this photo in File Explorer. Thus, "C:/2017/2017-01-15 Party/Received photo's/" should be opened and ideally DSC_0001.jpg selected. This functionality is not present I think. Instead, the "Album -> Open in File Manager" functionality only opens the top level album that is being displayed in the main screen, which in this example is "C:/2017." -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374356] "Show item in file explorer" as well as "open with"
https://bugs.kde.org/show_bug.cgi?id=374356 Sebas <djse...@home.nl> changed: What|Removed |Added CC||djse...@home.nl --- Comment #3 from Sebas <djse...@home.nl> --- +1 for this feature!! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 368734] Moving a hierarchy of tags (a tag with subtags) doesn't work and can lead to losing the complete hierarchy
https://bugs.kde.org/show_bug.cgi?id=368734 Sebas <djse...@home.nl> changed: What|Removed |Added CC||djse...@home.nl --- Comment #16 from Sebas <djse...@home.nl> --- I just ran into this problem on 5.6.0. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 380876] Tags in Digikam DB maintained after being removed from file and file re-scanned
https://bugs.kde.org/show_bug.cgi?id=380876 --- Comment #2 from Sebas <djse...@home.nl> --- Yes that's not the problem in this bug. The problem is that rescanning a tagless file still keeps Digikam displaying the removed tags, so Digikam must be loading them from database. Please read description again. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 380876] New: Tags in Digikam DB maintained after being removed from file and file re-scanned
https://bugs.kde.org/show_bug.cgi?id=380876 Bug ID: 380876 Summary: Tags in Digikam DB maintained after being removed from file and file re-scanned Product: digikam Version: 5.6.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tags Assignee: digikam-de...@kde.org Reporter: djse...@home.nl Target Milestone: --- Alright another tag issue here. Looks like bug 352711, but that one is outdated and I got some details here. 1. Assign EXIF XPKeywords tag to image using Windows Explorer (or possibly other software). 2. Add image to Digikam. 3. Remove EXIF XPKeywords from image using Windows Explorer. (Note: Digikam can't edit/remove EXIF XPKeywords tags anyways.) 4. Use any re(read) metadata functionality in Digikam to re(read) tags. 5. The removed EXIF XPKeywords tag is still being displayed by Digikam. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379918] Digikam writing tags in wrong order
https://bugs.kde.org/show_bug.cgi?id=379918 Sebas <djse...@home.nl> changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |INVALID --- Comment #3 from Sebas <djse...@home.nl> --- In version 5.6.0 I can not reproduce this problem. This is what I believe after a little digging: The software displaying the tags (Windows Explorer) reports IPTC Keywords first, then EXIF XPKeyworks. What I see in 5.6.0 is that existing EXIF XPKeywords are written to IPTC Keywords when modifying tags. For example when the EXIF XPKeyworks field contains 'A,' and the tag 'Z' is added, then 'A; Z' is written to IPTC Keywords. Then the software displaying the tags reads 'A; Z' from IPTC Keywords and then 'A' from EXIF XPKeyworks. Obviously the latter is being displayed already, thus ignored. Status changed to resolved + invalid for now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379922] Digikam won't remove tags set by Windows Explorer
https://bugs.kde.org/show_bug.cgi?id=379922 --- Comment #6 from Sebas <djse...@home.nl> --- There is a default tag rule, this one: Metadata Subspace: EXIF Name: Exif.Image.XPKeywords Special Options: NO_OPTS Alternative name: Alternative special options: NO_OPTS Separator: ; Set Tags Path: [V] The rule is enabled. I used the 'Reset to Default' button when checking for the second time. I can not add a rule for XPKeywords because when adding a rule, the only option allowed for 'Metadata Subpspace' is XMP. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379922] Digikam won't remove tags set by Windows Explorer
https://bugs.kde.org/show_bug.cgi?id=379922 --- Comment #4 from Sebas <djse...@home.nl> --- I did some deeper research. The field where Windows Explorer saves the tag has the name "XPKeywords" according to IrfanView. DigiKam has a metadata tag entry for this, but searching a bit further brought this up: http://dev.exiv2.org/boards/3/topics/530 So I guess that is the problem here? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379922] Digikam won't remove tags set by Windows Explorer
https://bugs.kde.org/show_bug.cgi?id=379922 --- Comment #2 from Sebas <djse...@home.nl> --- Thank you for the link. I tried 5.6.0 and it does not seem to be fixed. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379922] New: Digikam won't remove tags set by Windows Explorer
https://bugs.kde.org/show_bug.cgi?id=379922 Bug ID: 379922 Summary: Digikam won't remove tags set by Windows Explorer Product: digikam Version: 5.5.0 Platform: MS Windows OS: unspecified Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tags Assignee: digikam-de...@kde.org Reporter: djse...@home.nl Target Milestone: --- You can add or remove Digikam tags, and that works well, but in the end when you re-read meta data from file, the original tags (pre Digikam) are still there. In my case, Windows Explorer tags. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379918] New: Digikam writing tags in wrong order
https://bugs.kde.org/show_bug.cgi?id=379918 Bug ID: 379918 Summary: Digikam writing tags in wrong order Product: digikam Version: 5.5.0 Platform: MS Windows OS: unspecified Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tags Assignee: digikam-de...@kde.org Reporter: djse...@home.nl Target Milestone: --- 1. Digikam is not writing tags in A-Z order. 2. Also it is not writing tags in the order as selected by user. So what order does it use and why? Won't option 1 or 2 not be a better idea? -- You are receiving this mail because: You are watching all bug changes.
