Google has announced a Google Photos API

[NoLooseEnds]

More info:

• https://developers.googleblog.com/2018/05/introducing-google-photos-partner.html
• https://developers.google.com/photos/

Maybe that could help this project.

Or possibly merge with rclone (https://forum.rclone.org/t/google-photos-api/5593/10)?

[jhult]

Google's Go library is here: https://github.com/google/google-api-go-client/tree/master/photoslibrary/v1

[jhult]

Important note:

Note: All media items uploaded to Google Photos through the API are stored in full resolution at original quality. If your uploads exceed 25MB per user, your application should remind the user that these uploads will count towards storage in their Google Account.

Some users of this library may not desire this.

[jhult]

As per the rclone discussion (mentioned above), the retrieval of items (photos and videos) via the new API appears to be limited. There does not appear to be a way (currently) to retrieve the original image. Exif info and perhaps other info is stripped.

Before making a request to the baseUrl (when it is an image or a thumbnail for a video), profilePictureBaseUrl or coverPhotoBaseUrl, you must specify the dimensions that your application plans to display (so that the image can be scaled appropriately).

[simonedegiacomi]

Hi, sorry for the long wait!
I've read some parts of the API documentation and see two advantages in using the API in the tool:

1. At the moment the tool can break every time Google makes some changes to the web interface, the API is definitely more reliable;
2. Using the API each user should enable the API for his account and use a token, which should be more secure. Currently the authentication works storing the cookies in a plain text file (which can give full access to all your Google account to someone if stolen);

Since with the API there are also some drawbacks (limited space and need to create an authentication token) maybe it can be added to the tool the possibility to choose which method to use to upload the images.
The real question is if someone would really benefit of those advantages.

@NoLooseEnds regarding to rclone, I didn't know about that tool, so I don't really know how it should handle the photo mapping from the local folder to Google photos.
@jhult about the Exif info, I think that a solution could be to recreate them using the json object that the API sends with the base and product urls.

[nmrshll]

Hi there,

Shameless self-promotion here: I've worked lately on porting the uploader + google photos client library on top of the new google photos API. I think it's going to be more reliable / resilient to changes on google's side, and that we can work around all the drawbacks of using it:

• need to create an Oauth token: for the server side there is the official /x/oauth2 lib, and while it's usually a pain for client-only apps (desktop, cli, mobile...) I've worked on a library to make it simple at https://github.com/nmrshll/oauth2-noserver.
• paid / limited storage: only photos over 16MPx count towards paid storage, so downsizing on the client-side is definitely an option here for users who would want the library to store unlimited photos for free

I've split the work into two new projects, one for the CLI uploader, and one to use as a library to build go programs on top:

• https://github.com/nmrshll/gphotos-uploader-cli
• https://github.com/nmrshll/google-photos-api-client-go

[nmrshll]

So would it make sense to you to deprecate this project in favor of tools to work on top of the official API ?
I've made a PR for that (here), I only wanted to get your opinion about it first.

[simonedegiacomi]

Hi, great job! I like your idea to split the project in two repos.
I completely agree with you that the API would provide a more reliable library.
As @ammgws replied to the pull request, we need to take into account that the API uses the user quota.
I'll accept the pull request but i'll also add to the readme a note to specify that the new projects do not use the unlimited storage (if the photos are not less than 16mpx) yet.
In my opinion then there are 2 ways to add this functionality to the new projects: the first is to include this library in the new cli and add a flag to specify which library to use to upload the photos. The second would be to, as you said, compress the image on the client. I also would like to know your opinion, then I may contribute to implement one of the two ways.

[nmrshll]

Glad you appreciate the work ! In my opinion compression on the client seems like the way to go to solve this one problem, for the sake of simplicity : - for us maintainers: - the two libraries are very different in how they work: authentication with cookies and headless chrome vs oauth, different features available on the two APIs (no creating albums / uploading to albums on the old picasa one)). We'd end up maintaining two codebases, plus the glue code that unifies them, and they would be complicated to unify. - for users of the library: - less to learn in order to use the library (basically even if we wrapped the two libraries together they would have to know how both work to achieve authentication, and know which features are available on each API) I think it would be easier to point them to your repo if they need server-side compression right now, and over time to work to integrate that client-side in the new project. This would need less steps: - add a functional option in the upload method to specify original quality or compressed (and choose which should be the default if the option is not provided) - use an existing library to handle client-side compression ( I've worked with https://github.com/disintegration/imaging and it's good IMO ) and figure out good default parameters - same for video What do you think ? Le lun. 3 sept. 2018 à 10:14, Simone Degiacomi <notifications@github.com> a écrit :

…

Hi, great job! I like your idea to split the project in two repos. I completely agree with you that the API would provide a more reliable library. As @ammgws <https://github.com/ammgws> replied to the pull request, we need to take into account that the API uses the user quota. I'll accept the pull request but i'll also add to the readme a note to specify that the new projects do not use the unlimited storage (if the photos are not less than 16mpx) yet. In my opinion then there are 2 ways to add this functionality to the new projects: the first is to include this library in the new cli and add a flag to specify which library to use to upload the photos. The second would be to, as you said, compress the image on the client. I also would like to know your opinion, then I may contribute to implement one of the two ways. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGw1NOzv6rIwY0bjQOZST8suiGw_8vbMks5uXOTigaJpZM4T7bGV> .

[simonedegiacomi]

It's true, compression on the client side seems to be a definitive and easier solution.
For now who need the server side compression could use this project.

[andrea689]

I have tested https://github.com/nmrshll/gphotos-uploader-cli and the space available decrease even when the images are less than 16Mpx!!
In my opinion you should not deprecate this library.

[simonedegiacomi]

You're right. I've tried to upload some images with resolution lower than 16 Mpx and I've trusted the properties showed by Google Drive (which still reports a size of x bytes but with 0 bytes of storage used). A deeper look at the storage usage showed that the images are using space.
You can also notice this if you go on your Google Photos settings and click the recover space button.

Did you @nmrshll already noticed this?

(by the way, there's a feature request on the official issues page of the Google Photos API relative to the type of upload, maybe consider giving it a "star" to improve visibility)

[ammgws]

Can you reclaim the space afterwards?

[simonedegiacomi]

Yes, it seems that the recover space functionality works.