issue_comments

I'm not familiar with ExifReader. I wrote my own wrapper around exiftool because I wanted a simple way to write EXIF data when exporting photos (e.g. writing out to PersonInImage and keywords to IPTC:Keywords) and the existing python packages like pyexiftool didn't do quite what I wanted. If all you're after is the camera and shot info, that's available in ZEXTENDEDATTRIBUTES table. I've got an open issue #11 to add this to osxphotos but it hasn't bubbled to the top of my backlog yet.

osxphotos will give you the location info: PhotoInfo.location returns a tuple of (lat, lon) though this info is in ZEXTENDEDATTRIBUTES too (though it might not be correct as I believe Photos creates this table at import and the user might have changed the location of a photo, e.g. if camera didn't have GPS).

sql CREATE TABLE ZEXTENDEDATTRIBUTES ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZFLASHFIRED INTEGER, ZISO INTEGER, ZMETERINGMODE INTEGER, ZSAMPLERATE INTEGER, ZTRACKFORMAT INTEGER, ZWHITEBALANCE INTEGER, ZASSET INTEGER, ZAPERTURE FLOAT, ZBITRATE FLOAT, ZDURATION FLOAT, ZEXPOSUREBIAS FLOAT, ZFOCALLENGTH FLOAT, ZFPS FLOAT, ZLATITUDE FLOAT, ZLONGITUDE FLOAT, ZSHUTTERSPEED FLOAT, ZCAMERAMAKE VARCHAR, ZCAMERAMODEL VARCHAR, ZCODEC VARCHAR, ZLENSMODEL VARCHAR );

Very nice! Thank you for sharing that :+1: :) Will try it out!

I did have a bit of trouble with this one-off plugin getting it to load in the correct order - since I need authentication to work if EITHER the one-off plugin spots a token or my datasette-auth-github plugin authenticates the user.

That's why I want authentication as a core Datasette concept - so plugins like these can easily play together in a predictable manner.

I implemented bearer tokens in a private project of mine as a one-off plugin. I'm going to extract that out into a installable plugin soon. For the moment, my plugins/token_auth.py file looks like this: ```python from datasette import hookimpl import secrets

class TokenAuth: def init( self, app, secret, auth, ): self.app = app self.secret = secret self.auth = auth

async def __call__(self, scope, receive, send):
    if scope.get("type") != "http":
        return await self.app(scope, receive, send)

    authorization = dict(scope.get("headers") or {}).get(b"authorization") or b""
    expected = "Bearer {}".format(self.secret).encode("utf8")

    if secrets.compare_digest(authorization, expected):
        scope = dict(scope, auth=self.auth)

    return await self.app(scope, receive, send)

@hookimpl(trylast=True) def asgi_wrapper(datasette): config = datasette.plugin_config("token-auth") or {} secret = config.get("secret") auth = config.get("auth")

def wrap_with_asgi_auth(app):
    return TokenAuth(app, secret=secret, auth=auth,)

return wrap_with_asgi_auth

Then I have the following in `metadata.json`:json { "plugins": { "token-auth": { "auth": { "name": "token-bot" }, "secret": { "$env": "TOKEN_SECRET" } } } } `` And aTOKEN_SECRET` environment variable.

Interesting - do you know if there's anything the exiftool process handles that ExifReader doesn't?

I'm actually just going to extract a subset of the EXIF data at first - since the original photo files will always be available I don't feel the need to get everything out for the first step.

My plan is to use EXIF to help support photo collections that aren't in Apple Photos - I'm going to build a database table keyed by the sha256 of each photo that extracts the camera make, lens, a few settings (ISO, aperture etc) and the GPS lat/lon.

I don't think this is a useful feature.

Trickiness here is what tag to use. Do we use the tag of the installed copy of Datasette that is running datasette publish? That would mean you don't get the latest features in your deployed release.

Could hit an API to figure out the most recent version? Bit odd.

Could we output the version of Datasette that was deployed and tell people they can run --latest to force the most recent release?

Made a TIL: https://github.com/simonw/til/blob/master/pypi/project-links.md

For Datasette I'll go with: * Documentation * Changelog * Live demo * Source code * Issues * CI

The keys here can be anything: https://packaging.python.org/guides/distributing-packages-using-setuptools/#project-urls

So where do the icons come from? Turns out the PyPI site has special case rules for the icons here: https://github.com/pypa/warehouse/blob/2f00f4a9f208546ff0ebb6a6e61439021ca60a43/warehouse/templates/packaging/detail.html#L16-L60

Authorization: bearer xxx auth for API keys is a plus plus for me. Looked into just adding this into your Flask logic but learned this project doesn't use flask. Interesting 🤔

@simonw FYI, osxphotos includes a built in ExifTool class that uses exiftool to read and write exif data. It's not exposed yet in the docs because I really only use it right now in the osphotos command line interface to write tags when exporting. In v0.28.16 (just pushed) I added an ExifTool.as_dict() method which will give you a dict with all the exif tags in a file. For example:

python import osxphotos photos = osxphotos.PhotosDB().photos() exiftool = osxphotos.exiftool.ExifTool(photos[0].path) exifdata = exiftool.as_dict() tags = exifdata["IPTC:Keywords"]

Not as elegant perhaps as a python only implementation because ExifTool has to make subprocess calls to an external tool but exiftool is by far the best tool available for reading and writing EXIF data and it does support HEIC.

As for implementation, ExifTool uses a singleton pattern so the first time you instantiate it, it spawns an IPC to exiftool but then keeps it open and uses the same process for any subsequent calls (even on different files).

Released in 2.9 https://sqlite-utils.readthedocs.io/en/latest/changelog.html#v2-9

Released in 2.9 https://sqlite-utils.readthedocs.io/en/latest/changelog.html#v2-9

Docs: * https://sqlite-utils.readthedocs.io/en/latest/cli.html#dropping-tables * https://sqlite-utils.readthedocs.io/en/latest/cli.html#dropping-views