xevion / phototag

Rich tagging in the Terminal via Google Vision API

_{Built by Xevion}

Phototag is a personal tool I use to automatically generate and layer tags describing a photo in a fast and easy way. It uses Google's Vision API and supports IPTC metadata and Adobe XMP Sidecar files on Windows.

Features

• Automatic tagging of photos using Google's Vision API
  • Cheap, Fast and Accurate
• Minimal Data Usage
  • Compresses and thumbnails images before sending to Google
• Support for both JPEG and RAW
  • Store tags in JPEG via IPTC metadata
  • Store tags in RAW files via Adobe's XMP sidecar files
    • Full support for NEF only, CR2 and more untested
    • Requires a existing XMP file to be available

Installation

The project is currently not on PyPi yet. Until then, clone and install like so:

pip install

For development, install all dependencies with pipenv:

pipenv install
pip install -e .  # Editable mode to use the folder's current source files
# You can also install the Phototag package with
pipenv install -e .

Usage

Documentation of all functions is included by default with the --help flag.

# Copy the JSON authentication file for Google Vision API access
phototag auth [file]
phototag run

Uninstallation

pip uninstall phototag

How does it work?

This application is built in Python and utilizes the google-cloud python module family.

The basic process for each photo be tagged is as follows

1. Build relevant paths and identify important information used throughout the process
2. Save RAW files as JPEG using rawpy
3. Optimize JPEG files using thumbnailing and quality measures
4. Open and send the file to Google using the Vision API with google_cloud.vision
5. Compile and save the image's labels from Google
   • JPEGs use the iptcinfo3 module to save
   • RAW files use a messy implementation of the xml module to read and write tags (experimental) from and to the XMP Sidecar file used by Adobe
6. Delete the temporary (optimized) file and move the original image to the output folder.

The command used to access this program is phototag run, which would process and label all eligible images in the current working directory.

To-do

• Performance
  • Async/Threading/Parallelization
    • With configurable limits/targets
  • GPU-accelerated Image Thumbnailing
  • Memory/Disk Usage Metering
  • Image Hashing & Tag Caching
• File Filtering
  • Regex/Glob Pattern Matching
  • Include/Exclude Files/Directories
• Tag Filtering
  • Include/Exclude Tags
• Compatability
  • All popular RAW formats
  • Adobe XMP sidecar files
• Configuration
  • Pull from configuration files with runtime overrides
• Logging
  • Add additional logs
  • Allow configuration of verbosity/level application wide

phototag's Issues

Add commandline accessibility

This module is in desperate need of refactor with a end result containing a command line interface for accessing the functionality we want anywhere we want, on demand.

The ideal scenario would be opening a prompt up after importing a selection of files, and running something along the lines of phototag * to tag all files in the directory.

All files, NEF, JPEG or whatever else would be instantly tagged with keywords/tags provided by Google and add them to the IPTC metadata or a XMP sidecar file.

This would negate the current process of copying files in between the processing folder which can be very tedious and boring. This could also implement a recursive file searching ability so that I could tag and keyword hundreds or thousands of photos in a relatively small time frame, revolutionizing the project's usefulness to the common person.

Implement better extension handling

We handle distinguishing different functionality for different file extensions terribly.
This must be fixed in order to work in all situations.

Consider implementing better RAW processing method

As of now, processing RAW files literally deletes my system's RAM and will crash computers it's so slow, this is due to the insanely out of control multiprocessing threads implementation.

I think it's due time for a better implementation. One optimization would be thumbnails: extracting a full size JPEG from the RAW file, and then extracting a tiny thumbnail from that yields a large IO processing time that NEEDS to be cut down if full library processing is going to be anywhere near feasible.

preview-generator may yield a good results, but due to it being a rather new module, we should leave open options for multiple possible processing methods in the commandline options.

Perhaps looking into external image processing programs would be a good idea, including them as different 'thumbnail methods'.

Refactor code to use classes for simplified processing of files

Currently, classes are used for very little and need to be used more in order to store the abundant contextual information required to make smart decisions in the program.

My current setup with for loops is a failure of a system that is difficult to understand after coming back to it after a while.

I should implement classes that could be work together in order to create a async compatible program in the end, or utilize some kind of multiprocessing setup (I don't know what I'm talking about).