Google Takeout import doesn't use the "title" field from the metadata JSON field for the uploaded filename

[garyp]

Description

When Ente uploads images from a Google Photos Takeout directory, it uses the image's filename as-is (i.e. the same filename that the image has in the Google Takeout zip file) as the filename of the image within Ente. However, Google Takeout often truncates the actual image filename (and does all kinds of other weird filename transformations) before storing it in the zip file. The original filename is always saved in the image's metadata JSON file under the "title" field. Ente should be using the value of this "title" field during upload to preserve the original filename.

For example, my Takeout zip file contains these 3 files:

Takeout/Google Photos/Photos from 2019/00100lPORTRAIT_00100_BURST20190915164304772_CO.json
Takeout/Google Photos/Photos from 2019/00100lPORTRAIT_00100_BURST20190915164304772_COV(1).jpg
Takeout/Google Photos/Photos from 2019/00100lPORTRAIT_00100_BURST20190915164304772_COV.jpg

The 00100lPORTRAIT_00100_BURST20190915164304772_CO.json file contains:

{
  "title": "00100lPORTRAIT_00100_BURST20190915164304772_COVER.jpg",
  "description": "",
  "imageViews": "21",
  "creationTime": {
    "timestamp": "1568591085",
    "formatted": "Sep 15, 2019, 11:44:45 PM UTC"
  },
  ...

So when the 00100lPORTRAIT_00100_BURST20190915164304772_COV.jpg file is uploaded to Ente, it should be saved as 00100lPORTRAIT_00100_BURST20190915164304772_COVER.jpg instead of 00100lPORTRAIT_00100_BURST20190915164304772_COV.jpg. (I'm less certain if the filename of the 00100lPORTRAIT_00100_BURST20190915164304772_COV(1).jpg file should be similarly adjusted or not, as I haven't fully understood the semantics of these (1) files and why they sometimes have their own JSON files and sometimes they don't).

The use case, aside from improving the fidelity of the upload, is that I have some photos that I uploaded from my computer to Google Photos a while ago. Now I want to import everything from Google Photos to Ente, but I also want to import some of these old photos from my computer in case not all of them ended up in Google Photos. I need the original filename to be preserved so that Ente realizes that the photo being uploaded from my computer is the same one as the photo that was imported from Google Photos.

Proposed solution

From a brief glance through the Ente source code, I think the required change is in extractImageOrVideoMetadata() inside web/apps/photos/src/services/upload/upload-service.ts. Specifically, to use parsedMetadataJSON.title (which would have to be added as a new field) instead of fileName as the value of metadata.title if the parsedMetadataJSON.title field is set. I can put up a PR with the changes if you think this approach makes sense.

Version

v1.7.8

What product are you using?

Ente Photos

What platform are you using?

Desktop - Linux

[garyp]

I was looking at the code to see if I could fix this, and I'm a bit confused about Metadata.title vs FilePublicMagicMetadataProps.editedName. Is it safe to set Metadata.title (based on the title value from the JSON file) before the upload happens? Or does Metadata.title have to be the actual filename on disk that is being uploaded, in which case the modified name from the metadata JSON file should go into FilePublicMagicMetadataProps.editedName before upload?

For context, I'm looking at the code in

ente/web/apps/photos/src/services/upload/upload-service.ts

Line 986 in e0789b0

const extractImageOrVideoMetadata = async (

.

[mnvr]

I can put up a PR with the changes if you think this approach makes sense.

As requested in the Contributing guidelines, please do not start with code changes unless the functionality changes have been has been agreed to.

ps. I really appreciated you letting us know about that new Google Takeout suffixes yesterday 🙏, and so I'm only commenting to save you effort on PRs that are unlikely to be merged.

[garyp]

Thanks for the heads up! I was looking since I was already in that part of the code from the previous PR, and then it seemed like it could be a very small change to support this. But the purpose of my comment was exactly to ensure that the path I was considering would be ok before I started implementing anything.

so I'm only commenting to save you effort on PRs that are unlikely to be merged

So are you saying that you're unlikely to fix this particular issue? It seems like a bug to me, which is why I had created it as a GitHub Issue rather than a Feature Request discussion. But I know that sometimes one person's bug is another person's feature request 😀