Hacker News Reader

Comment by rubenv | Hacker News Reader

Author here: Note that I did select Original and it still seemed to compress the RAW file in Google Drive view. Single downloads do yield the original.

View on HN

Thanks for the article. I work on the photos team.

I will file bugs for the drive-sync issue and the issue with the large downloads failing and try to get some answers.

How do you give your partner full access? I've got 20k photos going back 17 years. My wife (another account in my Google Apps account) should have full access for searching, etc. Is that on the roadmap (just sharing isn't really a solution)?

Unfortunately we don't have a good answer for "family" accounts at this point.

It's definitely something that we've talked about internally and is something that I'd personally love to see in the product.

Thanks. It's SO important to at the minimum have a coadmin or partner/spouse account. Our whole life is in there and my wife can't get to them, which means they literally don't exist for her.

Love Photos App. There is a serious issue with Photos app on Android that is making many Apps fail while using intents to select photos from Gallery. See the Code Strip here:http://stackoverflow.com/questions/3401579/get-filename-and-...

(Trying to convert URI to Path String results in null with new Photos app since _data value is set to null for some reason).

Trying to reach someone who can look at Android Photos app since its breaking a large number of PhotoGraphy apps.

I should be able to file a bug on this if one hasn't been filed already.

You just filed it ;-) We'll fix this soon for local photos.

Nothing but love otherwise! In case it wasn't clear: Photos looks fantastic. Add an API and it's perfect.

Given that it doesn't have an API, I don't understand why it was announced at Google I/O. What is supposed to be a conference for developers has somehow turned into a place for Google to demo a ton of random new end-user product features.

In your opinion, only those products with API's available today should be announced? That sounds overly restrictive. By the same logic - Projects Jacquard and Vault shouldn't have been announced either.

I think it's fair to announce products so devs can be ready when the API becomes available.

First of all, "there were a couple things tacked on to the presentation that maybe could one day be used by a developer" is a pretty desperate argument, given that the keynote was three hours long and focussed on a ton of things that don't have any API at all, like Photos, and did not mention a single implication for a developer even for the things which had APIs, such as Now on Tap (which means that developers had no reason to bother going to the sessions on that feature, as it was clearly something designed for end users only; apparently it actually has a couple APIs).

However, sure: I'll bite. No: announcing random stuff that we can't play with and that they won't talk to us about is totally useless for developer. This entire event was just about causing people to go "wow, they are smart". I am a developer quite interested in 3D video, and so despite seeing Project Jump and going "ugh, another end-user product announcement", I figure I might as well talk to the engineers about it: only, they aren't willing to say anything about what might be available or how it works or essentially anything about their plans... so good luck "getting ready".

Regardless, the next thing you really need to defend, as this is what we are talking about: what are you, as a developer, doing to get ready for Photos? Google I/O has become less and less developer-focussed ever since it started (I have gone every year), and has turned into more and more of just a showcase of their end-user products. This year as the epitome, and all of the developers that I know who attended were quite disappointed; even the ones who still liked last year's somehow were now also saying "this event seems to have lost its purpose and is no longer useful".

I think a keynote should be more of 10,000 foot view

> Regardless, the next thing you really need to defend, as this is what we are talking about: what are you, as a developer, doing to get ready for Photos?

You can't imagine how unlimited storage of images and videos have no implications to devs and how we view curation of photos? Thats one less limitation to worry about.

I 100% agree that I/O is becoming less and less developer focused. Lots of non-developers want to attend (I blame the freebies they gave - looks like that has stopped so it might get better). I/O (or any other 'developer' conference) goes beyond the technical. There is a lot of self-promotion, PR, recruitment (in the HR sense, and recruitment into the 'developer ecosystem')

Only if they really plan to add an API. What about Hangouts for example? Did they announce an API for Photos?

To make sure I understand, what you would like is an API to get your original photos & metadata back out?

Isn't this compatible with the Picasa and Google Drive API's?

Is the Photo team part of Google+?

Photos works both for users with and without G+ account.

Have you tried Google Takeout [1]? I understand that will let you download all your data.

[1] - https://www.google.com/settings/takeout

Whoa, nice. Had no idea Google could provide me the _original_ files I uploaded to youtube.

Wow. That's a polished interface. Glad it exists

Unfortunately, it's a bit iffy for individuals that have unreliable internet. The download link expires after a while (last time I tried to do a large export).

Sorry about that. Did you try the move to drive option? One of the reasons we added the ability to move the finished archive to Drive was to allow users with unreliable internet connections to use the Drive Sync tool to sync the finished download down to their computer. I know it is a little inconvenient but it should make it possible to download a large archive over an unreliable connection.

(I work on the Takeout team)

Does your takeout archive include the drive takeout archive?

It does, there was a lot of debate on whether it should or not. If you have strong opinions one way or the other I would love to hear them as we are open to changing that behavior.

If you don't want that behavior, or just want to export part of your drive (or photos) collection you can expand that product in the Takeout UI and just select certain folders.

I didn't know about that option; I must have missed it at the time, or it wasn't available back then. I'll give it a go, thanks!

What does "compressing" a RAW file even mean? Is the actual content in the smaller downloaded version in some other format (e.g. JPEG)? Or is it simply truncated, either due to a bug or else stripping the actual RAW data, leaving only an embedded JPEG image?

It seems implausible that anyone would consider it a good idea to reencode a RAW file as a matter of course. Transcode it to process and/or compress it? Sure. But what comes out the other end isn't usually a native RAW file. (native RAW -> DNG workflows don't count.) This assumes that such a thing is even possible: e.g. that all RAW formats they'll see permit an alternate compressed encoding. If they did, someone needs a good stern talking-to. Pretty much the last thing that anyone who uses RAW files would expect is a workflow that tampers with the files while still allegedly remaining in the native RAW format.

Quick follow-up.

I can reproduce this on my own account.

I uploaded a raw (NEF) using desktop uploader using the "Original" setting. Downloading through the photos app returns the original NEF file.

Downloading via Drive returns a file with the original name ("Foo.NEF") that is actually a jpeg.

So this is clearly broken.

Bug filed. I will follow up when there is some kind of resolution.

Reply on news.ycombinator.com