Closed DrVanScott closed 11 years ago
Feel free to submit a patch.
Leo
On 14 April 2013 20:49, DrVanScott notifications@github.com wrote:
This is very important, because currently the pictures of an album are not in timely order. Google seems to use the file creation date of the shrinked file.
— Reply to this email directly or view it on GitHubhttps://github.com/leocrawford/picasawebsync/issues/6 .
ok here's part of it. I did not find any reliable python library to manipulate EXIF. So i use 'jhead' with a system call to copy over the exif tags.
The good news: It works. The bad news: The web albums are not automatically orderd. It is possible to apply a "order by date" by manually editing each album and click on 'sort by date' (may be called different, i just translated the german phrase). I have no idea if this could be automated via gdata?
Just an idea: You could add an exif header with the checksum of the original photo. It's not perfect as a later manipulation on the shrinked photo whould not affect the checksum. It will only work in the other direction.
Maybe also storing the checksum of the shrinked photo? So it would at least be possible to check the validity of the original photo checksum.
diff --git a/picasawebsync.py b/picasawebsync.py
index 759cb1a..6b58466 100755
--- a/picasawebsync.py
+++ b/picasawebsync.py
@@ -19,6 +19,7 @@ import time
import fnmatch
import tempfile
import Image
+from subprocess import call
PICASA_MAX_FREE_IMAGE_DIMENSION = 2048
@@ -44,6 +45,7 @@ def shrinkIfNeeded(path):
print "Shrinking " + path
im.thumbnail((PICASA_MAX_FREE_IMAGE_DIMENSION, PICASA_MAX_FREE_IMAGE_DIMENSION), Image.ANTIALIAS)
im.save(imagePath, "JPEG")
+ call(["jhead", "-te", path, imagePath])
return imagePath
except IOError:
print "cannot create thumbnail for '%s' - using full size image" % path
Thank you for the patch.
I'm happy to apply to patch, but would suggest a couple of minor changes before I do so: 1) Could we add a flag to enable the jhead call (so those without it installed can still have thumbails) 2) The readme needs updating to explain the dependency.
In terms of web album ordering, would fixing the web album date be what you need? If so I think this is what we need: http://stackoverflow.com/questions/4559030/not-able-to-change-a-date-of-my-picasa-web-albums-album-via-python-api
What album date would you set? The earliest photo in the album? Feel free to raise a new feature request and I'll have a go (or equally feel free to submit a patch)
I'm afraid I don't understand what you want to achieve with the exif data containing the checksum of the shrunk photo?
Leo
Am 21.04.2013 13:04, schrieb Leo Crawford:
1) Could we add a flag to enable the jhead call (so those without it installed can still have thumbails) Maybe check just for the existance of jhead?
2) The readme needs updating to explain the dependency.
i going to fork your project, apply the changes and finally start a pull request... In terms of web album ordering, would fixing the web album date be what you need? If so I think this is what we need: http://stackoverflow.com/questions/4559030/not-able-to-change-a-date-of-my-picasa-web-albums-album-via-python-api
What album date would you set? The earliest photo in the album? Feel free to raise a new feature request and I'll have a go (or equally feel free to submit a patch)
That would also be a great feature. As far as i understand this is the order of the albums (not the order of the pictures within an album). I suggested the EXIF idea to support the order of pictures within an album. There is an button 'order pictures by date' if you enter the 'edit album' menu in the web frontend. This didn't work for me as long as there was no exif information. The only thing that's now missing there is automation. I am still forced to do this steps manually for each album - and i have a lot of them... ;-) But i don't have enough insight into the google api wheather this is possible?
I'm afraid I don't understand what you want to achieve with the exif data containing the checksum of the shrunk photo?
That was just a first idea and i am not sure if this will work. There is this in your code:
self.remoteHash != self.getLocalHash()
This will not work if remote is a shrunk picture, or? Why not save the hash of the original picture in the exif of the shrunked one? So you can code something like this:
if existRemoteExifHash {
getRemoteExifHash != getLocalHash ...
} else
old behaviour
regards Henning
Maybe check just for the existance of jhead?
Even better.
2) The readme needs updating to explain the dependency.
i going to fork your project, apply the changes and finally start a pull request...
Sounds good.
In terms of web album ordering, would fixing the web album date be what you need? If so I think this is what we need:
What album date would you set? The earliest photo in the album? Feel free to raise a new feature request and I'll have a go (or equally feel free to submit a patch)
That would also be a great feature. As far as i understand this is the order of the albums (not the order of the pictures within an album).
That is correct. is that what you wanted fixed, or is there a problem within the albums too?
I suggested the EXIF idea to support the order of pictures within an album. There is an button 'order pictures by date' if you enter the 'edit album' menu in the web frontend. This didn't work for me as long as there was no exif information. The only thing that's now missing there is automation. I am still forced to do this steps manually for each album - and i have a lot of them... ;-)
I don't shrink my photos, so the exif data remains and I can sort within each album by date just fine.
But i don't have enough insight into the google api wheather this is possible?
What is it that you want applied automatically? To enable sorting by date?
Thanks for your ideas and contributions.
Leo
Hi Henning,
Sorry - missed the last bit of the email..
That was just a first idea and i am not sure if this will work. There is this in your code:
self.remoteHash != self.getLocalHash()
This will not work if remote is a shrunk picture, or? Why not save the hash of the original picture in the exif of the shrunked one? So you can code something like this:
if existRemoteExifHash { getRemoteExifHash != getLocalHash ... } else old behaviour
I /thought/ that the hash was of the full-size image and so it /should/ work already. Is this not the case?
I must admit I don't use the hashing myself as it is quite slow. I run using -c3.
Leo
regards Henning
— Reply to this email directly or view it on GitHubhttps://github.com/leocrawford/picasawebsync/issues/6#issuecomment-16724310 .
That is correct. is that what you wanted fixed, or is there a problem within the albums too?
First i wanted to correct the order of shrinked pictures. This was not possible as the exif information was missing. Now, with having exif data in the shrinked pictures, it is possible to reorder them manualliy via the web frontend. The other problem is, that the albums are not sorded chronoligically. It seems, that they are sorted by 'upload date'. It would be great if this could also be fixed.
What is it that you want applied automatically? To enable sorting by date?
Yes. Now the shrinked pictures have EXIF information, but the sort order is still not "by date". I need to go into each album via the webfrontend and click 'Edit - Sort by date'. It would be great if this could be done automatically.
I /thought/ that the hash was of the full-size image and so it /should/ work already. Is this not the case?
I didn't realized that there is allready something to handle comparision of original/shrunk pictures. I thought there was nothing. So please forget my idea ;-)
Regards Henning
Thank you very much for your contribution. The fix has now been applied (hopefully correctly).
I don't know of any way to get the web albums to sort by date order by default, I'm afraid.
This is very important, because currently the pictures of an album are not in timely order. Google seems to use the file creation date of the shrinked file.