Fixed
Status Update
Comments
co...@eversionsystems.com <co...@eversionsystems.com> #2
Thank you for your detailed report!
We'll take a closer look and let you know if we have any updates.
We'll take a closer look and let you know if we have any updates.
jf...@google.com <jf...@google.com> #3
We have just clarified the resumable upload protocol in our documentation here: https://developers.google.com/photos/library/guides/resumable-uploads
Note that this is slightly different from our previous protocol for resumable uploads. Please let us know if you are still having trouble following this new guide. Our apologies, but the general flow should be very similar to the previous definition.
Note that this is slightly different from our previous protocol for resumable uploads. Please let us know if you are still having trouble following this new guide. Our apologies, but the general flow should be very similar to the previous definition.
jf...@google.com <jf...@google.com> #4
Thanks for the updated documentation. I've given it a go and resumable uploads now seem to be working fine. Thanks.
ds...@gmail.com <ds...@gmail.com> #5
I've been testing downloading images using the "d" parameter, but the files returned are not the original files that were uploaded. The release note above reads "d download parameter, to download the original image". The link to the developer documentation doesn't say that the "original" image will be downloaded. Please can you confirm if the d parameter should download the original image that was uploaded to the api, or if this behavior has since changed.
mi...@gmail.com <mi...@gmail.com> #6
I've tested this again, and the file download is a mutated version of the file uploaded to Photos. If I use the web browser and go to photos.google.com , when I "Download" a photo it is byte-for-byte identical to the file I uploaded. If I use the API and attempt to get a copy, with the included "d" base URL, the file is mutated. Both some metadata is missing, as well the photo itself is modified (doing a pixel-for-pixel comparison shows subtle differences).
ph...@gmail.com <ph...@gmail.com> #7
I can confirm this is still broken and using the 'd' parameter does not return the original photo.
ma...@gmail.com <ma...@gmail.com> #8
This is still an issue
hi...@gmail.com <hi...@gmail.com> #9
How is it marked as fixed? =d parameter still doesn't work
Description
Only solution I found is to generate the biggest BaseUrl possible and save as image - but this isn't org file, only preview copy (so e.g. metadata is lost).