same pb if you don't select "export app tabs"

addendum

i put this as tag in the right panel:

Architecture/Architecte/Eric Dubosc

i found this in iptc

Eric Dubosc,Architecte,Architectecture

i found this in xmp

Architecture/Architecte/Eric Dubosc,Architecture/Architecte,Architecture

Mandriva 2010.0b1
digikam 1.0.0b4
kipi-plugins 0.5.0

pb still there

*** Bug 175260 has been marked as a duplicate of this bug. ***

Mandriva 2010.0rc1
digikam 1.0.0b5
kipi-plugins 0.7

same pb

it's a pity
if the pb is fixed i need no more to use picasa to export to picasaweb then i can abandon picasa

any news ?

do you plan to fix it ?

Created attachment 38516 [details]
Patch agianst kipi-plugins-0.8.0

This is because the Picasa plugin currently doesn't use the tags at all, even when explicitly told to:
picasawebwindow.cpp:
425 	void PicasawebWindow::slotUploadImages()

477 	 if(m_exportApplicationTags->isChecked())
478 	{
479 	// tagsFromDatabase=attribs["tags"].asStringList();
480 	}

Now, I don't know who put that there. Maybe there was a good reason back then. But if I just copy over whatever the flickr plugin is doing there right now, everything seems to work.

Also, I haven't done a lot of Qt programming. But I'm pretty sure you guys meant a checkbox instead of that radiobox with just one choice. And it should probably default to on like they do for the flickr plugin since most people will probably want that.

The patch attached fixes both #199145 and #205903.

Wait a second. Now I'm getting randomly missed tags. Sometimes if a photo have a dozen tags, only a few of them arrives. Sometimes if I re-upload the exact same image, I get a different set of successful tags. (some of the previously failed ones suddenly works) Maybe they commented that out for good reasons after all.

Let me see if I can find the problem. Looks like we must add tags separately after the upload in the Picasa API. And we must add them one by one. That seriously sucks compared to the simplicity in the Flickr API...

@siu chung

anyway many thanks for your job

Alright, I think I know why. Used Wireshark to capture all the packets. The requests are all sent correctly and Google received them. Even returned a "201 Created". But if you look closely at the Google API, they don't implement locking (probably for performance reasons). The way to update something is to download the whole thing and then upload the whole thing. Now consider this sequence:

1. Get tags to add tag 1 (received no tags)
2. Get tags to add tag 2 (received no tags)
3. Set tags to nothing + tag 1. Send.
4. Set tags to nothing + tag 2. Send.

Now tag 1 is lost. Classic race condition.

If I add a dialog box after every add tag message, it works. Also, the last tag never get lost. That makes me think this is the problem. The Google recommended solution is to use etags. Except that we can't. Because we're updating the tag entry here, not the photo entry. This is an oversight on Google's part IMHO. But not all hope is lost. :-)

I studied the official Google libraries and I found that they do this:
1. Upload picture.
2. Use response to construct photo entry object
3. Add keywords and everything to photo entry object
4. Call commit on the photo entry object to send changes.

On the wire, this is what happens:
1. Upload picture using HTTP POST
2. Server returns ATOM with all metadata of this picture
3. Library parse this XML into photo entry object
4. Caller modifies photo entry object
5. Caller commits
6. Library constructs new XML and do an HTTP PUT.

All we need to do is to emulate that and add all tags in one shot. (only one tag request hence no race conditions)

1. Upload picture using HTTP POST
2. Server returns ATOM/XML with all metadata
3. We parse and modify this XML. Add all the tags we want.
4. Send back this XML using HTTP PUT.

This approach has the advantage of allowing other stuff such as Geotags in the future. We can specify that explicitly for image files where Google fails to parse the IPTC Geotags. (saw some bugs on bugs.kde.org) All done in a single shot.

I've made a new patch. Seems to work. Tested with around 30 photos with 6 or 7 tags each. All arrived correctly. Feel free to change the coding style if you don't like it. Future wish: would be nice if someone can parallelize the picture resizing. You could resize the next picture while this picture is uploading.

Created attachment 38567 [details]
New patch with fix for multiple tags

great job ! :=)

(In reply to comment #12)
> Created an attachment (id=38567) [details]
> New patch with fix for multiple tags

if you have time
to also fix this bug which is similar but about movie
movie export works well but not exporting legend, tags, geotag
https://bugs.kde.org/show_bug.cgi?id=215664

this would be complete

thanks very much

digikam 1.0.0rc
kipi-plugins 0.8

same pb : tags are not exported (export tags checked or not

digikam 1.0.0rc
kipi-plugins 0.9

same pb : tags are not exported ("export tags" checked or not)

digikam 1.0.0
kipi-plugins 1.0.0

same pb : tags are not exported ("export tags" checked or not)

SVN commit 1067206 by cgilles:

apply pâtch #38547 from Siu Chung to export Tags to PicasaWeb
BUGS: 199145


 M  +2 -2      mpform.cpp  
 M  +31 -43    picasawebtalker.cpp  
 M  +4 -3      picasawebtalker.h  
 M  +1 -1      picasawebwindow.cpp  
 M  +1 -1      picasawebwindow.h  
 M  +4 -1      uploadwidget.ui  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1067206