How to use versioning?
Locked
12
12
 
|
Hello,
I'd like to use versioning in digiKam 2.6.0 but I have some problems. I've googled some documentation but if I repeat those steps here the result is different. First I "Enabled Non-Destructive Editing and Versioning". I also played with "Always show original images" and "Always show intermediate snapshots" but they made no difference. Then I edited a image in the image editor. I only made a single change (converted to black and white) and save as new version. Now the image editor shows me the new image in the "Image History" and the used filter in "Used Filters" in the "Versioning" sidebar. Back in digiKam album view I can see both images but no matter which one I select I can't see the complete image history in the versioning sidebar, it only shows the current selected image. "Used Filters" is empty, too. After that I selected both versions of the image and ran "Group selected here". Still no change in the versioning sidebar. I wonder if this is the expected behavior or what I'm doing wrong. Another thing I'm wondering is the shown image of grouped images. It seems to depend on where one runs "Group selected here". Shouldn't this depend on "Always show original images"? Or what is that setting for? I hope someone can help me to get used to digiKam versioning. Best regards, Andreas -- http://andreas.vdr-developer.org --- VDRAdmin-AM & EnigmaNG & ExtRecMenu & VDRSymbols VDR user #303 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
I have not tried versioning or grouping myself yet but I have found out
from this list that 'Save as new version' is badly labelled and does not do what you seem to think it does. If you have versioning enabled then just choose 'Save'. This will update the image with a new entry in the image history. When versioning is enabled it is not possible to make a change without it being recorded in the image history. 'Save as new version' creates a new instance of the image that has its own change history which is separate from the original. I really do think that 'Save as new version' is a confusing label and it is not intuitive as to its purpose until it is explained, although I have trouble thinking up a better one. Perhaps 'Save as separate instance'. Andrew _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Am 16.06.2012 00:07, schrieb Andrew Goodbody:
> I have not tried versioning or grouping myself yet but I have found out > from this list that 'Save as new version' is badly labelled and does not > do what you seem to think it does. If you have versioning enabled then > just choose 'Save'. This will update the image with a new entry in the > image history. When versioning is enabled it is not possible to make a > change without it being recorded in the image history. 'Save as new > version' creates a new instance of the image that has its own change > history which is separate from the original. > > I really do think that 'Save as new version' is a confusing label and it > is not intuitive as to its purpose until it is explained, although I > have trouble thinking up a better one. Perhaps 'Save as separate instance'. > > Andrew I was one of these who were confused... and understood it only after explanations here. However I must confess that the included help texts are very clear and say it all, one just has to look at it :-) I guess, using an "uncommon phrase" could maybe lead more people to search the help. "Save as new version" is (for me) something common and I understand it just as "save as". If it does not do what I expected I think its an error of the program and not of my misunderstanding... My proposal therefore would be something like *"start new versioning tree"* or the like. A phrase that is not used in other known contexts for other purposes and therefore would make the user curious: what is this? He'd investigate using the very complete help functions or just try it out and think about what's happening... ------- To once again use the occasion: Thanks digikam team for this fantastic tool and the huge work behind it! Of course such a rich application can never be "error-free" and "perfect for everybody". But I use it every day for my professional work (with versioning disabled) and it's unique way to work is just the best I have ever found. (I also have a Mac and what that offers in this kind of image tools is just poor compared to digikam). regards Daniel -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com personal facebook: http://www.facebook.com/mars.fotografo google+: https://plus.google.com/109534388657020287386 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Daniel Bauer <[hidden email]> writes:
>> >> I really do think that 'Save as new version' is a confusing label and it >> is not intuitive as to its purpose until it is explained, although I >> have trouble thinking up a better one. Perhaps 'Save as separate instance'. > > My proposal therefore would be something like *"start new versioning > tree"* or the like. > > A phrase that is not used in other known contexts for other purposes > and therefore would make the user curious: what is this? He'd > investigate using the very complete help functions or just try it out > and think about what's happening... > For this purpose, wouldn't "Branch image" be suitable, as this is exactly what is happening and a well defined VCS term? Maybe some users will not directly understand it, but as mentioned the help text would put them on track. As a bonus, it will lead them to VCS tutorials in googling. :) Another option could be "Clone image" which is more intuitive (but this usage is not universal; e.g. a "clone" in inkscape is linked to it's master and depend on it's properties - a change in the master is reflected directly in the clone) -- Johnny _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Daniel Bauer-2
Hello,
2012/6/16 Daniel Bauer <[hidden email]>: > Am 16.06.2012 00:07, schrieb Andrew Goodbody: > >> I have not tried versioning or grouping myself yet but I have found out >> from this list that 'Save as new version' is badly labelled and does not >> do what you seem to think it does. If you have versioning enabled then >> just choose 'Save'. This will update the image with a new entry in the >> image history. When versioning is enabled it is not possible to make a >> change without it being recorded in the image history. 'Save as new >> version' creates a new instance of the image that has its own change >> history which is separate from the original. >> >> I really do think that 'Save as new version' is a confusing label and it >> is not intuitive as to its purpose until it is explained, although I >> have trouble thinking up a better one. Perhaps 'Save as separate >> instance'. >> >> Andrew > > > I was one of these who were confused... and understood it only after > explanations here. What explanations do you refer to exactly? I still see no change in the results, no matter if I use "Save" or "Save as new version". > However I must confess that the included help texts are very clear and say > it all, one just has to look at it :-) What included help texts do you mean? The tooltips of the two save buttons? Well, at least the German translation makes me think "Save as new version" is the right one. I've also opened the digiKam and showFoto English handbooks, but they are dated back to 2009/2010 so they tell you nothing about versioning. > I guess, using an "uncommon phrase" could maybe lead more people to search > the help. "Save as new version" is  (for me) something common and I > understand it just as "save as". If it does not do what I expected I think > its an error of the program and not of my misunderstanding... > > My proposal therefore would be something like *"start new versioning tree"* > or the like. > > A phrase that is not used in other known contexts for other purposes and > therefore would make the user curious: what is this? He'd investigate using > the very complete help functions or just try it out and think about what's > happening... If both save buttons have a different function (which they do not have for me yet) and "Save as new version" starts a complete new image tree with no reference to the original image, then it should really get a new name, at least from what I can read from your descriptions. But *please* can we get back to my problem? What can be wrong here? Best regards, Andreas BTW: I really want to rant. I like digiKam very much and I've never seen anything that fits my needs better. I have some difficulties with the new 2.x features like versioning, but that may be due to my lack of experience with them. -- http://andreas.vdr-developer.org --- VDRAdmin-AM & EnigmaNG & ExtRecMenu & VDRSymbols VDR user #303 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Am 16.06.2012 14:58, schrieb Andreas Mair:
> Hello, > > 2012/6/16 Daniel Bauer <[hidden email]>: >> I was one of these who were confused... and understood it only after >> explanations here. > > What explanations do you refer to exactly? > I still see no change in the results, no matter if I use "Save" or > "Save as new version". I was referring to the explanations received here: http://mail.kde.org/pipermail/digikam-users/2012-March/016020.html I don't use versioning, but us much as I understand (please correct anybody who knows better if I'm wrong): when versioning enabled: - "save" will write a new file that is *connected* to the last file (considered as a step further that can be undone later). Usually only this last saved version will be visible in the album (you can change that in the settings). "Save as new version" will write a new file that is *not* connected with the last file. You will see both, the last version and the new version in the album. The new file is considered like an original and you can start versioning with this new file (later using "save" only) independent of the "original-original"-file and its versions... Anything UN-cleared? :-) >> However I must confess that the included help texts are very clear and say >> it all, one just has to look at it :-) > > What included help texts do you mean? The tooltips of the two save > buttons? the info-texts in the settings-dialog where you can en/disable versioning and the hovering texts over the save-options in the dialogs Well, at least the German translation makes me think "Save as > new version" is the right one. I also use the German translation. However, I think whether you use versioning or not depends on your personal needs and taste. I, me, for my self, prefer to decide myself when I need a "snapshot" (and therefor save it with "save as" - versioning disabled - under a new name) and keep track of my versions with my own personal system of folders and names. But I understand that many people like to have these tasks kind of automated. They always see the last result and can easily go back to earlier versions without having to remember to save them manually at the time or later remember which was what step... For me it's great that I can disable versioning, I hope it will stay like this ;-) kind regards Daniel -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com personal facebook: http://www.facebook.com/mars.fotografo google+: https://plus.google.com/109534388657020287386 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
2012/6/16 Daniel Bauer <[hidden email]>:
> Am 16.06.2012 14:58, schrieb Andreas Mair: > >> Hello, >> >> 2012/6/16 Daniel Bauer <[hidden email]>: > > >>> I was one of these who were confused... and understood it only after >>> explanations here. >> >> >> What explanations do you refer to exactly? >> I still see no change in the results, no matter if I use "Save" or >> "Save as new version". > > > I was referring to the explanations received here: > http://mail.kde.org/pipermail/digikam-users/2012-March/016020.html > > I don't use versioning, but us much as I understand (please correct anybody > who knows better if I'm wrong): > > when versioning enabled: > > - "save" will write a new file that is *connected* to the last file > (considered as a step further that can be undone later). Usually only this > last saved version will be visible in the album (you can change that in the > settings). > > "Save as new version" will write a new file that is *not* connected with the > last file. You will see both, the last version and the new version in the > album. The new file is considered like an original and you can start > versioning with this new file (later using "save" only) independent of the > "original-original"-file and its versions... > > Anything UN-cleared? :-) > > >>> However I must confess that the included help texts are very clear and >>> say >>> it all, one just has to look at it :-) >> >> >> What included help texts do you mean? The tooltips of the two save >> buttons? > > > the info-texts in the settings-dialog where you can en/disable versioning > and the hovering texts over the save-options in the dialogs > > > Well, at least the German translation makes me think "Save as >> >> new version" is the right one. > > > I also use the German translation. > > However, I think whether you use versioning or not depends on your personal > needs and taste. I, me, for my self, prefer to decide myself when I need a > "snapshot" (and therefor save it with "save as" - versioning disabled - > under a new name) and keep track of my versions with my own personal system > of folders and names. > > But I understand that many people like to have these tasks kind of > automated. They always see the last result and can easily go back to earlier > versions without having to remember to save them manually at the time or > later remember which was what step... > > For me it's great that I can disable versioning, I hope it will stay like > this ;-) yes, it will, but we will improve it in the future. At least 2.6.0 come with important fix about from Marcel... Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Johnny
> For this purpose, wouldn't "Branch image" be suitable, as this is > exactly what is happening and a well defined VCS term? Maybe some users > will not directly understand it, but as mentioned the help text would > put them on track. As a bonus, it will lead them to VCS tutorials in > googling. :) We decided against this for this very reason: we cant expect our users to be familiar with our development tools and the way software developers think. In the C++ code, the thing is called a branch, and it's implemented as a directed acyclic graph just as git uses it but that doesnt help users for whom a branch is something to be found in the wood. > Another option could be "Clone image" which is more intuitive (but this > usage is not universal; e.g. a "clone" in inkscape is linked to it's > master and depend on it's properties - a change in the master is > reflected directly in the clone) "Clone" is an interesting metaphor. But I fear it can be confused with Clone Tools as an image editing operations (which we dont have in digikam, or rather have it in the form of unfinished code.) _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Andreas Mair
> I'd like to use versioning in digiKam 2.6.0 but I have some problems. > I've googled some documentation but if I repeat those steps here the > result is different. > > First I "Enabled Non-Destructive Editing and Versioning". I also > played with "Always show original images" and "Always show > intermediate snapshots" but they made no difference. > > Then I edited a image in the image editor. I only made a single change > (converted to black and white) and save as new version. Now the image > editor shows me the new image in the "Image History" and the used > filter in "Used Filters" in the "Versioning" sidebar. Back in digiKam > album view I can see both images but no matter which one I select I > can't see the complete image history in the versioning sidebar, it > only shows the current selected image. "Used Filters" is empty, too. > After that I selected both versions of the image and ran "Group > selected here". Still no change in the versioning sidebar. > I wonder if this is the expected behavior or what I'm doing wrong. It must be right in the sidebar, toggling "Always show..." depends on identical information, and grouping is unrelated. So I tried to reproduce the original problem (take one image, b&w, save as new version), but all information is available for me in the versioning sidebar. If you can reliably reproduce it with 2.6.0, please take a (small) image, reproduce the bug, create a report on b.k.o, and attach original and result files for testing. > Another thing I'm wondering is the shown image of grouped images. It > seems to depend on where one runs "Group selected here". Shouldn't > this depend on "Always show original images"? Or what is that setting > for? Dont confuse grouping with versioning. It's not directly related. Yes, if you select A+B and choose "Group select HERE" on image A, then A will be group leader; if you run it on image B, then B will be group leader. As sometimes you may want to group on A, and sometimes on B. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Daniel Bauer-2
I'm not happy with your and Andrew's explanation of "Save as new version" which seems to imply "disconnection" or "new instance separate from the original." What do we do traditionally? Open xy.jpg, edit, 1) "Save" -> overwrite xy.jpg Further editing: Only the edited version is available 2) "Save As" -> xy-2.jpg is written as a second image Further editing: Can start from xy.jpg or xy-2.jpg Further editing: Now with versioning, we will never ever overwrite the original on disk. As a consequence of technical decisions we made, it is necessary that under the hood, any save operation including simple "save" will create a new file. (this is a purely technical decision. We could simply store the actions and replay them when needed and never store a file on disk, but there's a million reasons to avoid this). So with versioning, as seen from digikam Open selected image, 1) "Save changes" -> image is overwritten Further editing: Edited version is available 2) "Save As new Version" -> a second image is shown Further editing: Can start from first or second image Note: I really dont care for filenames here. The image history of both possible results is completely identical with the exception of one flag at a certain location. Whichever you choose, you will not become disconnected from any previous history. The versioning sidebar will always show all related images (if you are on branch 1, it will show all images on branch 2 within the limits of a categorized flat list) > > - "save" will write a new file that is *connected* to the last file > (considered as a step further that can be undone later). Usually only > this last saved version will be visible in the album (you can change > that in the settings). > > "Save as new version" will write a new file that is *not* connected with > the last file. You will see both, the last version and the new version > in the album. The new file is considered like an original and you can > start versioning with this new file (later using "save" only) > independent of the "original-original"-file and its versions... > > Anything UN-cleared? :-) _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Andreas Mair
In case you have switched to "tree mode" of the versioning sidebar, there's a small bug. Please try the combined view. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Daniel Bauer-2
On 16/06/12 09:05, Daniel Bauer wrote:
> Am 16.06.2012 00:07, schrieb Andrew Goodbody: >> I have not tried versioning or grouping myself yet but I have found out >> from this list that 'Save as new version' is badly labelled and does not >> do what you seem to think it does. If you have versioning enabled then >> just choose 'Save'. This will update the image with a new entry in the >> image history. When versioning is enabled it is not possible to make a >> change without it being recorded in the image history. 'Save as new >> version' creates a new instance of the image that has its own change >> history which is separate from the original. Ahh! now I understand! >> I really do think that 'Save as new version' is a confusing label and it >> is not intuitive as to its purpose until > I was one of these who were confused... and understood it only after > explanations here. ... > My proposal therefore would be something like *"start new versioning > tree"* or the like. Yes that would make more sense to me. As Marcel pointed out not everybody will 'get' the metaphor of trees or branches, but at least some of use will! -- John Stumbles http://stumbles.org.uk :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-: _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Andreas Mair
Hello,
finally I got it working! I ran tests under a new user without modifying any setting in digiKam and versioning worked. After that I compared the two digiKam settings files and tried to find out which setting in my non-working user was the reason. And here it is: digiKam settings: Metadata / Behavior / Reading and Writing Metadata If I enable "Write to sidecar files" and set this option to anything but "Write to XMP sidecar for read-only image only" versioning *doesn't* work (even if image is read-only). I mean: - on that page I've only enabled "Read from sidecar files" and nothing else => versioning works (history OK) - now enable "Wright to sidecar files" and set it to "Write to XMP sidecar for read-only image only" => versioning still works - now set "Wright to sidecar files" to "Write to sidecar only" or "Write to image and XMP Sidecar" => versionimng *not* works Is this reproduceable by anybody? Best regards, Andreas 2012/6/15 Andreas Mair <[hidden email]>: > Hello, > > I'd like to use versioning in digiKam 2.6.0 but I have some problems. > I've googled some documentation but if I repeat those steps here the > result is different. > > First I "Enabled Non-Destructive Editing and Versioning". I also > played with "Always show original images" and "Always show > intermediate snapshots" but they made no difference. > > Then I edited a image in the image editor. I only made a single change > (converted to black and white) and save as new version. Now the image > editor shows me the new image in the "Image History" and the used > filter in "Used Filters" in the "Versioning" sidebar. Back in digiKam > album view I can see both images but no matter which one I select I > can't see the complete image history in the versioning sidebar, it > only shows the current selected image. "Used Filters" is empty, too. > After that I selected both versions of the image and ran "Group > selected here". Still no change in the versioning sidebar. > I wonder if this is the expected behavior or what I'm doing wrong. > > Another thing I'm wondering is the shown image of grouped images. It > seems to depend on where one runs "Group selected here". Shouldn't > this depend on "Always show original images"? Or what is that setting > for? > > I hope someone can help me to get used to digiKam versioning. > > Best regards, > Andreas > > -- > http://andreas.vdr-developer.org --- VDRAdmin-AM & EnigmaNG & > ExtRecMenu & VDRSymbols > VDR user #303 -- http://andreas.vdr-developer.org --- VDRAdmin-AM & EnigmaNG & ExtRecMenu & VDRSymbols VDR user #303 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
2012/6/19 Andreas Mair <[hidden email]>:
> Hello, > > finally I got it working! > > I ran tests under a new user without modifying any setting in digiKam > and versioning worked. After that I compared the two digiKam settings > files and tried to find out which setting in my non-working user was > the reason. > > And here it is: > digiKam settings: Metadata / Behavior / Reading and Writing Metadata > If I enable "Write to sidecar files" and set this option to anything > but "Write to XMP sidecar for read-only image only" versioning > *doesn't* work (even if image is read-only). > I mean: > - on that page I've only enabled "Read from sidecar files" and nothing > else => versioning works (history OK) > - now enable "Wright to sidecar files" and set it to "Write to XMP > sidecar for read-only image only" => versioning still works > - now set "Wright to sidecar files" to "Write to sidecar only" or > "Write to image and XMP Sidecar" => versionimng *not* works > > Is this reproduceable by anybody? > If it's reproducible by someone, please open a file about in bugzilla with all condition listed before... Best Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Andreas Mair
> digiKam settings: Metadata / Behavior / Reading and Writing Metadata > If I enable "Write to sidecar files" and set this option to anything > but "Write to XMP sidecar for read-only image only" versioning > *doesn't* work (even if image is read-only). > I mean: > - on that page I've only enabled "Read from sidecar files" and nothing > else => versioning works (history OK) > - now enable "Wright to sidecar files" and set it to "Write to XMP > sidecar for read-only image only" => versioning still works > - now set "Wright to sidecar files" to "Write to sidecar only" or > "Write to image and XMP Sidecar" => versionimng *not* works Versioning involves information stored in image metadata, which may explain that a bug in metadata writing can affect versioning. Are you sure that you run libkexiv2 newer than April? I strongly recommend not to use sidecars with any older version. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hello Marcel,
2012/6/19 Marcel Wiesweg <[hidden email]>: > > >> digiKam settings: Metadata / Behavior / Reading and Writing Metadata >> If I enable "Write to sidecar files" and set this option to anything >> but "Write to XMP sidecar for read-only image only" versioning >> *doesn't* work (even if image is read-only). >> I mean: >> - on that page I've only enabled "Read from sidecar files" and nothing >> else => versioning works (history OK) >> - now enable "Wright to sidecar files" and set it to "Write to XMP >> sidecar for read-only image only" => versioning still works >> - now set "Wright to sidecar files" to "Write to sidecar only" or >> "Write to image and XMP Sidecar" => versionimng *not* works > > Versioning involves information stored in image metadata, which may explain > that a bug in metadata writing can affect versioning. > > Are you sure that you run libkexiv2 newer than April? I strongly recommend not > to use sidecars with any older version. I'm using kde-base/libkexiv2-4.8.3 and media-gfx/digikam-2.6.0 on a Gentoo Linux box. Is this new enough? Best regards, Andreas -- http://andreas.vdr-developer.org --- VDRAdmin-AM & EnigmaNG & ExtRecMenu & VDRSymbols VDR user #303 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Wed, 20 Jun 2012 08:17:18 +0200
Andreas Mair <[hidden email]> wrote: > Hello Marcel, > > 2012/6/19 Marcel Wiesweg <[hidden email]>: > > > > > >> digiKam settings: Metadata / Behavior / Reading and Writing > >> Metadata If I enable "Write to sidecar files" and set this option > >> to anything but "Write to XMP sidecar for read-only image only" > >> versioning *doesn't* work (even if image is read-only). > >> I mean: > >> - on that page I've only enabled "Read from sidecar files" and > >> nothing else => versioning works (history OK) > >> - now enable "Wright to sidecar files" and set it to "Write to XMP > >> sidecar for read-only image only" => versioning still works > >> - now set "Wright to sidecar files" to "Write to sidecar only" or > >> "Write to image and XMP Sidecar" => versionimng *not* works > > > > Versioning involves information stored in image metadata, which may > > explain that a bug in metadata writing can affect versioning. > > > > Are you sure that you run libkexiv2 newer than April? I strongly > > recommend not to use sidecars with any older version. > > I'm using kde-base/libkexiv2-4.8.3 and media-gfx/digikam-2.6.0 on a > Gentoo Linux box. > Is this new enough? On Fedora libkexiv2-4.8.3 was built on 30th April, so that library version must precede that date. I can see a libexiv2-4.8.4, dated in early June. There don't seem to be any later upstream versions, so this is probably the version which has the post-April fixes. -- Brian Morrison _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hello,
I've finally found time to update to KDE 4.8.5 and digiKam 2.8.0 and test again. But nothing changed. For your convenience I copy'n'pasted my findings from a previous mail: digiKam settings: Metadata / Behavior / Reading and Writing Metadata If I enable "Write to sidecar files" and set this option to anything but "Write to XMP sidecar for read-only image only" versioning *doesn't* work (even if image is read-only). I mean: - on that page I've only enabled "Read from sidecar files" and nothing else => versioning works (history OK) - now enable "Wright to sidecar files" and set it to "Write to XMP sidecar for read-only image only" => versioning still works - now set "Wright to sidecar files" to "Write to sidecar only" or "Write to image and XMP Sidecar" => versioning *not* works By talking about "versioning" I mean that I open an image in the digikam editor, apply some filter and then call "save changes". Any ideas what's sill wrong? I've appended the used components at the end of this mail. Best regards, Andreas === Used components === digiKam version 2.8.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 LibCImg: 130 LibClapack: external shared library LibExiv2: 0.21.1 LibJPEG: 80 LibJasper: 1.900.1 LibKDE: 4.8.5 (4.8.5) LibKExiv2: 2.1.0 LibKGeoMap: 2.0.0 LibKdcraw: 2.0.1 LibLCMS: 119 LibLensFun: external shared library LibLqr: internal library LibPGF: 6.12.27 - external shared library LibPNG: 1.5.10 LibQt: 4.8.2 LibRaw: 0.14.4 LibTIFF: LIBTIFF, Version 4.0.2 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble Widget: 0.13.3 (stable release) Parallelized PGF codec: No Parallelized demosaicing: Yes Database backend: QSQLITE LibKface: 2.0.0 LibKipi: 1.3.0 LibOpenCV: 2.3.1 Libface: 0.2 2012/6/20 Brian Morrison <[hidden email]>: > On Wed, 20 Jun 2012 08:17:18 +0200 > Andreas Mair <[hidden email]> wrote: > >> Hello Marcel, >> >> 2012/6/19 Marcel Wiesweg <[hidden email]>: >> > >> > >> >> digiKam settings: Metadata / Behavior / Reading and Writing >> >> Metadata If I enable "Write to sidecar files" and set this option >> >> to anything but "Write to XMP sidecar for read-only image only" >> >> versioning *doesn't* work (even if image is read-only). >> >> I mean: >> >> - on that page I've only enabled "Read from sidecar files" and >> >> nothing else => versioning works (history OK) >> >> - now enable "Wright to sidecar files" and set it to "Write to XMP >> >> sidecar for read-only image only" => versioning still works >> >> - now set "Wright to sidecar files" to "Write to sidecar only" or >> >> "Write to image and XMP Sidecar" => versionimng *not* works >> > >> > Versioning involves information stored in image metadata, which may >> > explain that a bug in metadata writing can affect versioning. >> > >> > Are you sure that you run libkexiv2 newer than April? I strongly >> > recommend not to use sidecars with any older version. >> >> I'm using kde-base/libkexiv2-4.8.3 and media-gfx/digikam-2.6.0 on a >> Gentoo Linux box. >> Is this new enough? > > On Fedora libkexiv2-4.8.3 was built on 30th April, so that library > version must precede that date. > > I can see a libexiv2-4.8.4, dated in early June. There don't seem to be > any later upstream versions, so this is probably the version which has > the post-April fixes. > > -- > > Brian Morrison > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users -- http://andreas.vdr-developer.org --- VDRAdmin-AM & EnigmaNG & ExtRecMenu & VDRSymbols VDR user #303 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
> I've finally found time to update to KDE 4.8.5 and digiKam 2.8.0 and > test again. But nothing changed. > > LibKExiv2: 2.1.0 I checked the tags set in the libkexiv2 repository. Apparently all relevant sidecar fixes are still only in master (4.9) and not in the 4.8 branch. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Thu, 30 Aug 2012 21:28:47 +0200
Marcel Wiesweg <[hidden email]> wrote: > > > I've finally found time to update to KDE 4.8.5 and digiKam 2.8.0 and > > test again. But nothing changed. > > > > > LibKExiv2: 2.1.0 > > I checked the tags set in the libkexiv2 repository. Apparently all relevant > sidecar fixes are still only in master (4.9) and not in the 4.8 branch. It doesn't help that the library version and the libkexiv2 package version don't seem to be related in any sensible way. How are we supposed to know which KDE version is equivalent to which exiv branch? -- Brian Morrison "I am not young enough to know everything" Oscar Wilde _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |