abstrctn / lightroom-album-import Goto Github PK

If an image is removed from an album, it won't be included in the sorted_image_ids or sorted_image_paths outputs. But it would be nice to provide an option to remove the image / sidecar / json files from source control as well.

This would necessitate some way of differentiating any files associated with a given album from the other assets in a repo.

• One option would be to remove any items in a download_directory that aren't active in the current album, but ideally I think we'd allow for a download location that isn't unique to an album.
• Another option might be storing an album identifier in an Exif tag; any non-current images in the download_directory that match the album's tag could be targeted for deletion.
• We could also call this out of scope.

For the second option, we'd have to choose a tag to store the album ID.

• xmpDM:Album - This seems highly correlated to music albums however, so may be inappropriate
• IPTC:JobID or IPTC:OwnerID - Don't seem to be widely standardized
• imageUniqueID - Currently used to store the Lightroom asset ID, but could be turned into a compound field of both the album and image ids

The intention of the hide_stacked_assets parameter was to exclude all images within a stack except for the image at the front of each stack, so that the list of images that a user sees in Lightroom (and their order) match what is downloaded in the action.

It looks like I was mistaken about how that parameter works in the underlying API, however:

• Setting it to true hides every item in the stack, including the front asset
• That parameter doesn't seem to even work in the unauthenticated version of the API

But it looks like stacks and their contents are still available in that API, by adding stack to the subtype querystring parameter.

Within the stack assets, the cover.id seems to refer to the asset ID of the first image in the stack. And the stack assets themselves have a sort field that seems to be reflected in the returned asset order.

    {
      "id": "2adc3595bc694263b5acc89ad...",
      "type": "album_asset",
      "asset": {
        "id": "3eb54d9f08524b95af610c4233...",
        "type": "asset",
        "subtype": "stack",
        "payload": {
          "userUpdated": "2023-04-28T20:59:17.965Z",
          "cover": {
            "id": "c00bbaa6f9c34824b359d2c2b..."
          },
        }
      },
    },

Unfortunately, the underlying assets are also present, and other than the cover asset, there isn't anything that distinguishes "hidden" assets from non-stacked assets. This could be handled with hide_stacked_assets, but without returning that data, we don't have access to the metadata we need for the cover image.

For now, this could be handled by making two requests, one with subtype=image,stack and hide_stacked_assets=true, and the second with subtype=image and hide_stacked_assets=false.