Google Photos API | Hacker News Reader

Google Photos API

developers.google.com

182 pointsldcdc66 comments

Use the Google Photos API to build smarter photo and video features for your product.

Developer site: https://developers.google.com/photos

With the API you can help users transfer, share and bring their content into your app more easily (including features like auto-organized categories and creating link-shareable albums).

API is now launched to General Availability, with official client libraries and sample apps for Java & PHP (and more in the works!).

Large app integrations are also encouraged to join the Google Photos Partner Program. Check the developer site for more info.

Open articleView on HN

There's alot of comments here about Google shutting down its services.

Here's what Amazon does with products it no longer wants:

Consider SimpleDB, one of the first of the Amazon web services and effectively dead. But still has a live page, and still works and is online https://aws.amazon.com/simpledb/

But is not listed in the Amazon Web Services product lineup:

https://aws.amazon.com/products/

Presumably if you had built something on it many years ago (which I did), it would still be working today. Maybe the lesson for Google is that instead of killing things, leave them working but without future development. And instead of radical pricing change, make pricing change for new customers and leave the old ones on the existing pricing. Sure people might be unhappy about the changes but they are less likely to be enraged and lose trust in Google.

This post from Amazon Web Services CTO https://www.allthingsdistributed.com/2016/03/10-lessons-from... says:

5. APIs are forever

This was a lesson we had already learned from our experiences with Amazon retail, but it became even more important for AWS’s API-centric business. Once customers started building their applications and systems using our APIs, changing those APIs becomes impossible, as we would be impacting our customer’s business operations if we would do so. We knew that designing APIs was a very important task as we’d only have one chance to get it right.

yahoo shut down pipes only after it was pretty much abandoned

SimpleDB still works though.

>5. APIs are forever

Microsoft does a lot of work in that direction too, there are workarounds and fallbacks to older API behavior everywhere around the place.

I think this is also compatible with Linus' mantra; "Don't break userspace". (Obviously there is a limit, Linus did elaborate on those limits recently).

I really don't like it when APIs stop working. There are plenty of ways to get people off the old API without disrupting them or annoying anyone, as you mention, an option is to simply stop advertising the old version and maybe make it more expensive (or less accessible) to new customers.

Having a stable API that I can bet a product for 10 years (or more) on is something that developers (and users) like and should be a huge plus when deciding between product offerings from companies.

Use the Google Photos API to build smarter photo and video features for your product... until we deprecate the API in a couple years time and leave you up shit creek.

This is a tired meme given that the number of Google services closed has been mostly going down since 2013. See also https://en.wikipedia.org/wiki/List_of_Google_products#Discon...

  2006 3
  2007 4
  2008 5
  2009 7
  2010 4
  2011 16
  2012 19
  2013 11
  2014 7
  2015 6
  2016 11 (actually 8 if you don't count things that got merged into other things)
  2017 4
  2018 2

This wikipedia list is missing a lot of APIs, it seems more related to products -- For example, the QPX API (which I used) was shut down this April and is nowhere in that list. Your numbers are lower than they should be.

I'm pretty sure the qpx API was a purchase, not something Google started. So it's arguable that you can categorize it the same way.

I'm pretty sure shutting down critical parts of acquired products is a major part of the problem.

agreed. Just because they were acquired doesn’t mean that the acquisition customers didn’t feel the pain from being forced deprecated

Notable there would be the recent incident where Twitter bought some ML startup for abuse analysis and shut down customers overnight with almost no warning.

According to your own citation, Google deprecated multiple APIs every year. So the odds of Google cutting off access to an API you use may be decreasing... But it's still nowhere near zero, and it's still a valid concern.

Yeah, but that's not unique to Google. It's a valid concern with any API or service that you don't control.

Does Google shut down stuff at a greater rate relative to anyone else? Are the odds better or worse if X had been run by company Y?

The question is not “is Google better or worse than average?” It’s: what is the risk of building an app on a Google API? The risk is high, and it’s not worth it. Their track record is abysmal. Sure, if you pick a random provider out of a hat, maybe Google is better. But if you look for a solid provider or better just build your own service instead of trying to glom onto someone else’s (someone with no real incentive to see your product succeed).

> Yeah, but that's not unique to Google. It's a valid concern with any API or service that you don't control.

As mentioned by others Amazon seems to have a policy along the lines of "APIs are forever".

That's really nice. Google could make the same pledge. They do well enough and will likely be around for a very long time.

I don't care anymore. I am now in the process of removing Google Maps from every system we run because of their screwing over their users and their devs. I have thousands of dollars of time to spend ahead of me because of the changes to Google Maps this past month alone.

I get it, it's expensive to run maps, it's not free. But this is multiple-times burned by these guys. So the threshold of toleration is lower with Google than other businesses/services.

Nothing free from Google is ever going on anymore of my sites or software unless it is setup with an alternative already in place so when they do _anything_ ridiculous, they can be dropped instantly. But as of right now, the plan is a complete purge of Google.

What are you switching to for web and mobile users for maps?

I'm doing what the parent post is doing, switching to OpenMapTiles which I'll be running on my own. Still using Google maps on Android because it's free and doesn't generate enough volume to cost me much.

I too take caution with Google APIs after the maps price hike. I've also abandoned Twitter API after their streaming API shutdown

I actually don't want to advocate a specific map software right now, as we are likely to switch between multiple systems until we find one we like.

OpenStreetMaps ( https://www.openstreetmap.org ) is the data source for most other mapping systems though.

Suffice to say, I am setting it up so that it can be more easily replaced if need be.

It's not really tired if your app/service was dependent on one of the ones shut down. Granted, most services/APIs have a lifecycle and won't last forever. What makes Google different/frustrating is their habit of shutting things down either in their prime (I.e when goog realizes they won't get 100s of millions of users) or well before the tail end of their lifecycle leaving those who placed a bet on said service high and dry. I view it not so much as a meme as a warning/reminder.

How is this a tired meme? Looks like 99 services were shut down since 2006.. You just proved their point. The consensus here is that you shouldn’t build anything critical with their APIs, and I agree

So if I built anything on Google's platform ... in the last 10 years or so, you are saying "only" 99 products or platforms (by your own numbers) have been shut down, possibly taking your business with it.

That number is crazy high. That there has been a slight trend the last 2 years does in no way make up for the significant risk shown by those other numbers.

You have to be crazy to base your business on the Google platform.

Tired meme indeed.. https://news.ycombinator.com/item?id=17971516

Or increase the price of the API by ten times.

Seriously, it should be a rule of thumb that if you are not big enough to negotiate with Google for a secured pricing, don't rely on their API exclusively in your project

Or raise the API usage costs from under $100 a month on average to over ~$15,000 a month like they just did/are doing with the Google Maps/Places/Geocode API's. Not kidding. They're shutting thousands of websites, businesses down because of this. They gave everyone two months notice to effectively shutting them down.

Their acceptable use policy seems to be fishy

> Innovate, don't duplicate

> Don’t make a substitute for Google Photos or use this API to create, train, or improve (directly or indirectly) a similar or competing product or service. For instance, if your app’s primary aim is to provide a general purpose photo gallery app, it’s a substitute for Google Photos.

Ouch. I didn't catch that.

IANAL, but this seems to rule out the use of this API in a number of places where it would be useful (plugin for open source photo management seems to be directly targeted etc).

I can understand why they don't want to allow me to train my image recognition software using their API, but this phrasing makes me really wonder what it is for except syncing.

Thanks, that's helpful feedback. If you have a specific use case in mind, please drop us a note through the partner program and our team can provide you with specific guidance: https://developers.google.com/photos/partner-program/

Not a partner so not sure my feedback is relevant there, but an obvious use case would be integration, probably as a plugin into all kind of open source galleries, photo browsers, organizers etc.

Also, generally the wording is vague enough to cover almost anything, which means at some point, sooner or later you might have to rely on the judgement of some random future googler to prevent all your integrations being destroyed.

Wow, fantastic! This will allow me to drag Google’s sync app for Mac directly into the trash, which I’ve been dying to do for years! Then I can write some kind of program that finds the duplicated medium, small, and thumbnail sizes of all my photos, and the cropped faces, that Google senselessly uploaded from my Aperture/Photos library to the tune of 4 million+ garbage files. This API could make it possible for me to actually get value from Google Photos again.

Please build this. Google's Sync app is terrible. I don't understand their logic - if you have a high res photo on Google Photos, but the original on your PC (Which will be higher quality) it won't overwrite it. You need to delete the cloud version and upload the original. It's stupid - I had a free Photo account with "high res" photo syncing for free, then I moved to a paid account and I have to delete all my photos and re-sync - which doesn't work on Mac, so now I only have 1/2 my photos backed up... So annoying.

Yeah, sharp edges everywhere. My favorite feature is if it can’t convert your raw images to JPEG, instead of skipping them it stores them in Drive as non-photo data, which can fill up your quota and cause your Gmail account to stop receiving mail. It’s probably the worst software that Google has put their brand on.

You are lucky. I had some corrupted and very big photos in my filesystem. Since Google sync couldn't convert it, the software decided to upload the corrupted file to Google Drive as is. Sure I've checked to sync just photos in high res.

Result: the corrupted uploaded files filled my Google Drive, so I couldn't receive emails anymore in Gmail! Lost 7 days of messages till diagnosed the problem.

Hi there! I haven't launched yet, but you're throwing me a softball here.

I am building it: https://PhotoStructure.com

Cleaning up the mess left from early-adopting N photo apps and websites that subsequently shut down is why I took on this project. I've got 20-odd hard drives that have accumulated over the years, filled with backups and libraries from Apple Photos, Aperture, Picasa, several hundred gigs of Google Takeout tarballs, and other ancient DAM apps. I wanted a single, organized, deduped, copy of my photos and videos. Skip the thumbnails, the files that are missing original EXIF headers, or have suffered bitrot.

Finally, I've got a single folder hierarchy I can rsync to my NAS or wherever, and know I got everything. There's a simple SQLite db I use for persistence, and a web server that sits on top of it that makes browsing and searching your whole library feel serendipitous.

So yeah, it's Google Photos that lives on your bookshelf. Viva the distributed web! I'm looking into the applicability of dat and ipfs for secure sharing soon.

I've got a limited number of beta users trying it out right now. If you're willing to share your feedback, please consider signing up. The beta is free.

> I've got 20-odd hard drives that have accumulated over the years, filled with backups and libraries from Apple Photos, Aperture, Picasa, several hundred gigs of Google Takeout tarballs, and other ancient DAM apps.

I'm in a similar boat. What I'd like to know is: where are the duplicates and what can I safely delete? Anything that can help me clear it up would be a godsend!

This was the approach I originally was considering (to do in-place duplicate deletion), but eventually gave up due to the impact of "undiscovered features" in my code.

The approach I've settled on which should work for most people is to establish a new library, with unique copies of each of your originals, skipping exact SHA matches and invalid files.

In your case, though, you'd run PhotoStructure in its "don't copy into the library" mode. Once it finishes scanning your drives, you can run a simple SQL query against your SQLite db to get a list of duplicate files. That query will be in the FAQ.

Thanks, that would be a great help!

I could manage that query but your average user wouldn't. How about a way to export it to a CVS file so it can be viewed and filtered in the users choice of spreadsheet app?

That's a good idea, thanks.

I have on the order of terabytes of digital photos from QuickTake through Nikon's various Ds to the Sony A9, with various pocketables and all the generations of iPhone along the way. I have a quarter million iCloud Photos images, 30K on Flickr, etc.

So this looks fantastic! Subscribed ... very willing to be a beta tester and provide detailed feedback.

However, the problem I'm finding is a small percentage of file corruption from all the storage upgrading and copying over the years, meaning no given file can be 100% trusted to be a valid original.

I haven't found any file or photo deduplication tools with the savvy to figure out which of two identically sized and timestamped files is the least corrupt image.

In many cases, a second generation is viewable while the original is present but unusable. This most often applies to very old Aperture libraries that got copied from NAS to NAS over the years, where a "master" may be corrupt but it still has a viewable generated high res cache as a JPEG.

Implication is the "structure" of the image files themselves has to be analyzed ... is this an uncorrupted viewable image?

Note that with JPEGs and various flavors of RAW, renderers will still happily open and display the file but what humans view can evidence bit rot. Conversely, some files are detected as corrupt by file examination, but can be viewed without problem.

To offer "principle of least loss" for mass merge of diverse collections, this would have to be figured out.

> which of two identically sized and timestamped files is the least corrupt image

What I've found on my older hard drive backups was file corruption due to bitrot or file truncation.

I use `jpegtran` to validate JPEG bytestreams, `dcraw` to validate RAW images, and ``ffmpeg` to validate videos. At least for my quarter-million-file corpus, those tools detect corruption sufficient enough for me to want to skip the file. I actually had to write a bit rotter to write tests for this, and do glitch inspection.

> To offer "principle of least loss" for mass merge of diverse collections, this would have to be figured out

Every unique SHA gets copied into your library (if you have copies enabled), but any given asset will have 1 or more asset files (that are merged in the UI and DB). To minimize risk from bugs^H^H^H^H "undiscovered features," PhotoStructure never moves or deletes files excluding it's own cache and db.

man why do so many sites add this shitty robot checking shit for even signin up for mailing lists. your non-existent project even has it. i'm tired of selecting cars/bridges and fire hydrants for 2 minutes at a time only for the robochecker to fail. the audio option workaround doesn't even work anymore, i'm really sick of captchas

go to google drive and delete the wrongly uploaded directories. all changes will be propagated to photos.

Tried that, Backup-N-Sync just puts them up again.

https://developers.google.com/photos/library/guides/api-limi...

> All media items uploaded to Google Photos using the API are stored in full resolution at original quality. They count toward the user’s storage.

Are there some commercial decision behind this?

Currently the Google uploader is worse than the previous backup tool, and you can't make third party uploader with this API.

Thanks for the question. This is something the team is actively considering in: https://issuetracker.google.com/issues/111193036

Our primary concern is ensuring that users have full control over the quality of media that's added to their library (so currently the API defaults to always uploading in original quality).

Clearly there are ways that problem can be solved, so please suggest this use case in the issuetracker and star the issue (so we have a sense of developer interest & you can be kept in the loop on updates).

If we can resize the pictures ourselves and be sure they don't count against our quota that would solve my problem.

As it stands it seems people are interpreting it as if all images, regardless of size, will count against the quota.

If this is just a documentation issue I'd be happy to see it fixed. Anyways, as mentioned upthread it would be great to have an option in the api or something.

Please also tak a look at this: https://news.ycombinator.com/item?id=17956695

As I read it now it limits the usage so broadly and vaguely that I'd be hesitant to put any serious effort into it.

Slightly unrelated:

Google Photos is a great product but for me it has one huge drawback. You cannot remove a person from a shared album after adding them. You or anyone an album is shared with can accidentally share the album with any other person and once that happens, only way to stop them from accessing your photos is to delete the whole album. Deleting the album means losing all photos, comments and likes added by others. Also sharing an album always generates a link that can be used by anyone to access the album. I haven't found a way to share only with people without generating the link.

Looking through the documentation, this can be concerning:

> Photo storage and quality

> All media items uploaded to Google Photos using the API are stored in full resolution at original quality. They count toward the user’s storage.

It would be nice to specify a photo to be stored as "high resolution" like you may as a gphotos user. Every photo uploaded via the API counting towards a user's storage might deter them from using the integration.

I guess you could just do the same type of resizing they do before uploading although I agree it should be built into thr API.

Maybe I misinterpreted this line, but it seems like even a resized photo will count against the storage quota.

If a resized photo is stored in "original quality" mode, that's still counting as quota. "Lossy quality" mode photos straight up don't count.

With some work this could replace the desktop app Google bought and discontinued (Picasa) and remove the dependency on Drive Sync

Finally! This looks great, there was a way to get access to Google Photos via the Drive API but a dedicated one is a nice surprise.

However... I noticed a clause that requires a "Commercial license" if your app prints photos:

> If your product transfers a user’s photos onto physical goods (such as photo prints or t-shirts) and you charge money for this service, you must have a Commercial license. For more information, see the Google Photos partner program.

Anyone know how much this costs or why this is the case?

I hope we get something besides Backup and Sync as a replacement for Google Photos Uploader. My workflow broke when Backup and Sync doesn't work the same way, and not as consistent. I can't only upload photos, and it seems to try to vacuum up other files, so I've just told it to stop since they broke the Googel Photos Uploader API.

Ooh wow this looks like I can finally add a bunch of features to my "google photos in your new tabs" chrome extension (http://www.photosnewtab.com/)

Maybe I'll finally be able to de-dupe the low-resolution photos Picasa uploaded against the higher-resolution photos that photo importer tool uploaded. I'll just have to write the de-duping tool myself. Great!

I want to be able to sync tagged faces from photos to contacts. Or at least access the tagged face via the API.

My photos, my contacts. What's the big deal?

someone tell Apple

I have to do a tedious manual export and upload to get photos from Apple Photos desktop app to Google Photos cloud

(and I don't want a sync app that uploads everything)

Here is Google shutting down another API (which are forever until they're not), and still no sign of a Google Keep API.

Come on Google, you can do better than this.

>enjoying a soon to be deprecated API at the price of letting the G access to all your data I shiggy diggy

Would it be possible to hack together a usable manual tagging system via the API? I don't mean the automatic face tagging, or built-in tagging functionality (I assume Google Photos doesn't have it). I mean would it be possible to use the API to insert keywords into the description fields and reliably search the description fields

What about timing. I need a API for sync photos for my mobile app. Now what to use?

Won't this enable hackers to make apps to steal people's images/photos given that many users don't think twice before authorizing apps to collect all the data they want just like we saw recently in case of top trending apps stealing data on Apple Store?

Reply on news.ycombinator.com