Minor modification to jpeg image data to trigger cloud resync. Bad idea?

Started by joakimk, September 02, 2017, 10:22:43 AM

Previous topic - Next topic

joakimk

I've got a jpeg question. I've made an android app which edits exif and iptc metadata to images on the device (using Apache Commons Imaging). This works fine (thanks to lots of very helpful advice from this forum) but I have a new challenge.

If the phone syncs photos to some cloud service, and the user adds metadata at a later time, the image is not re-synced to the cloud. It seems the modification, to metadata only, is not sufficient for the device/cloud to re-sync. If I, however, change the JPEG to, say, greyscale, then the image file is updated in the cloud (without making a duplicate).

Is it a decent idea to modify, say, one pixel of the JPEG when the user adds metadata, such that the service will resync the file (including metadata)?

StarGeek

Jpegs are a lossy format.  Changing a pixel would require a re-encoding of the image inducing a loss of quality.  Doing this multiple times leads to a lot of degradation of the image.  This would be unacceptable to me.

Figuring out what does and does not trigger the re-sync would be more important, IMO.  I'm not familiar with the android operating system but maybe updating the file timestamps?  Try adding empty bytes to the end of the file and see how many bytes it takes to trigger a re-sync.  For a jpeg, any bytes after the EOI marker should be ignored by a proper image viewer.  Then try adding to a metadata tag that can take a bunch of data.  For example, adding a few K to xmp:Description.
"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype

joakimk

Thanks for the reminder of re-encoding. That's an obvious deal breaker. I have tried adding data to the metadata sections of the JPEG file (exif and iptc), and this does for some reason not trigger a re-sync. However, adding empty bytes after the EOI marker is a good idea worth a try!

I have experimented with Google Cloud (Google Photos). I guess the trick is to find out what triggers a resync, and perhaps this varies across different cloud services. Maybe Dropbox would resync on changed metadata, I'll check that too. 

joakimk

So I've been experimenting with this some more, up against Google Photos and Dropbox, and I've made some observations:

Google Photos
* It seems the metadata and the image file are saved separately in the cloud service.
* It doesn't seem to be possible to change/update the metadata associated with the image file.

So, whatever metadata the image file contains (or does not contain) when the image is first synced, is what you're stuck with in the cloud. This (possibly empty) meta data is what you'll get when you later download the file, even after it's been updated (re-synced) in the cloud (e.g. if you modify the image, crop it, etc).

Dropbox
* Using normal "Dropbox" app, meta data does not seem to ever be synced -- even when meta data is added before first sync.
* Using "Dropsync" app for Android, meta data is synced (and re-synced if it changes on the device)  :)

It seems the standard Dropbox app (latest version as of writing) ignores, and apparently strips off, meta data.

joakimk

So... I guess I'm wondering if anyone here knows something about these services :)

StarGeek

I can pretty much guarantee that Dropbox isn't stripping off any metadata.  For them to alter someone's file would negate the usefulness of their service.  Ignoring metadata, especially on a resync, is a different story.

And Google Photo definitely doesn't change any metadata.  It may not re-read the metadata upon re-uploading, but it doesn't change any of it.  While testing GP, I've uploaded, changed data on the website, and downloaded the image and there was no change to any data. 

I haven't checked what the results are when you modify the image online and download.

But from the sound of it, neither site re-reads the metadata when the file is reuploaded. 
"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype

joakimk

Hey, thanks for checking! :)
I repeated the experiment for Dropbox, and this time it seems to work: If I disable sync, take a photo and add meta data, and then enable sync, then I find the same meta data in the version downloaded back from Dropbox. That's a good start, and that's the same results I can achieve with Google Photos.

However, the real problem is that changes to meta data does not seem to trigger a re-sync... with neither GP nor Dropbox :( This is so strange, because the file has indeed changed (different checksum, updated last-modified timestamp). As I described above, a third-party app "DropSync" will re-sync the image on meta data change.