update notes

README.md

@@ -123,6 +123,8 @@ Roadmap
 -------
 
 - TODOs:
+    - need `nullable=False` on columns where applicable
+    - 0-5 rating option for photosets
     - give uuids a style like `this`
     - search next/prev buttons to match feed links
     - search tag selector to match tag picker links
@@ -142,6 +144,17 @@ Roadmap
     - nullable=False for all columns possible
     - check/clean no-js fallbacks
     - check gps skew in "nearby" section
+    - camera info / database
+        - show the camera information on each photo page
+        - create a catalog of known cameras by extracting the info from the exif
+        - associate cameras with photos and allow search by camera
+        - cameras can be nicknamed
+        - all of this with lenses also?
+    - make it clearer that the download/preview button gets a (converted) original size image
+    - make the map view markers colored in some logical manner
+        - rainbow across age spectrum?
+        - 4 colors (with shades) for the 4 seasons?
+        - colorblindness?
 
 - Flesh out CLI:
     - data manipulation
@@ -189,3 +202,44 @@ Prior work / modules to use:
 * https://face-recognition.readthedocs.io/en/latest/face_recognition.html
 * https://www.pyimagesearch.com/2018/06/18/face-recognition-with-opencv-python-and-deep-learning/
 * https://github.com/JohannesBuchner/imagehash
+
+
+Image processing framework
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Purpose:
+
+Some way to mass process photos in batches. For example, the batch jobs could:
+    - load metadata from images that is newly supported
+    - process new faces in images
+    - create a downloadable mini-album
+    - proactively generate thumbnails
+    - replace thumbservice, the video thumb service
+
+Could also have:
+    - a session-based mechanism to "select" photos
+        - e.g. to add them to a batch processing job or album later. Like a clipboard of sorts
+
+Design notes:
+    - general ui:
+        - use a tag multiselector (like the search page) to pick the "input" images for a batch job
+        - for now, we can have a drop-down to select which job to run
+        - there could then be a second-stage config screen for the job where
+            - additional parameters for the job could be set
+                - like what?
+            - the job could run some sort of validation
+        - there is a Job List screen that displays an index of current / past jobs
+
+    - job executor:
+        - "for now", a SimpleExecutor service.
+        - it's an http service (like thumbservice lol) that is similarly notified by http hook when a job is created by
+          the ui/api (except we pass the ID in the http call this time and it looks up the details from the DB)
+
+    - internal notes:
+        - tables / cols:
+            - Job: id, uuid, name?, job_name, status(new, running, done, error)
+            - JobTarget: id, job_id, type(tag, set, photo), target
+                - this indicates where a job should get images to work on
+                - there is a numeric ID in the `target` column that can be any of a Photo, PhotoSet, or Tag
+                - which it is, is determined by the `type` column
+                - therefore the code can know which method to locate the file with