A modern, web-based photo management server. Run it on your home server and it will let you find the right photo from your collection on any device. Smart filtering is made possible by object recognition, face recognition, location awareness, color analysis and other ML algorithms.
Automatic tags such as objects and colours have a significance score based on the area in the image that it is related to and how much confidence there is. Higher significance values of the selected filter tags should appear higher in the result list.
Currently, due to Python's import logic, all other models get imported when one of the runners is loaded. This is apparent on the public demo at the moment when importing Tensorflow fails but not all models use this library.
Hi, @damianmoore , I'm a logo designer. I saw your project and seems like it will be a successful project. If you want, I can design a logo for this project. What do you think?
Create a neural network model based on Google's NIMA to determine how appealing each image is. We can use this score to work out the best photo to show when multiple images are being represented by one, such as album covers, a cluster of items on a map, a summary of a month or event.
I'm sure that I'd closed down and reopened localhost:8888 previously, but when trying to reload it today, it simply says that localhost failed to connect, ERR_CONNECTION_REFUSED. Any suggestions?
When people chose to view a photo full screen, that photo could be very large. We should fetch the image server-side (over internet if necessary) and convert/resize/compress it so it is viewable to the user quickly.
As noticed by @Soharic here, some cameras/phones give unrecognisable make/model names in their metadata. The user should be able to override the names of their cameras with a custom name.
Format the make name as best as possible in the UI (title case)
See if there is a compiled list of model -> common name translations
Add support for cloud storage providers (AWS S3, Google Cloud storage) for photo and thumbnail storage. This will allow scaling to an almost infinite number of photos and users. We will support Amazon S3 (-compatible) and Google Cloud Storage (GCS) initially. This ticket does not include anything to do with encryption - there is a separate ticket #59 to add that after. Until encryption is added, all data is publically readable as browser will load the files directly.
AC:
One bucket configured via environment variables for storing photo data
One bucket configured via environment variables for storing cache data
User model extended to have quota_size and current_size (in bytes)
Library model extended to have quota_size and current_size
Upload feature to upload to S3 or GCS if Library path starts with s3:// or gcs:// protocols
Upload feature increases User and Librarycurrent_size values on each successful upload (DB transaction)
Background job to calculate Library and User current sizes once a day to correct any rounding/upload anomilies
If file is a raw type then raw processor should download from object storage and upload JPEG version to same location
Thumbnailing job able to retrieve from cloud storage and save to cache location which other analyzers will use
Ensure other analysis jobs are using 4K thumbnailed versions and trigger thumbnailer first if they don't find cached thumbnail
Ensure thumbnailer is locking correctly so multiple cloud storage downloads and writes do not occur in parallel
Thumbnailer URL needs to redirect to cloud location HTTPS endpoint
Dismissed ideas:
Add Bucket model to assign a bucket to a User.
Idea was for quota to be applied for user and they can then create as many libraries as they like. Doesn't seem like Google or AWS allow size quotas to be applied to buckets
User should be able
Fields: UUID, type (S3 etc), User, path, current_size (needs to be kept updated periodically), max_size (optional)
Having separate ID means it can be transferred to another user if required. Also Google recommends not including user IDs in bucket names.
If user wishes to create new Library then they can add it to user's existing bucket
If there is a Chromecast or similar on the local network and icon should display (and possibly a notification) to connect and use the TV as a presentation device. Only a full photo at a time should be displayed, not the whole screen view that is on the presenter's phone/laptop.
When zoomed out to the whole world we do not want pins for every photo that has a location. A group of images that are in a similar area should be clustered and represented by a different kind of point - a number or a stack images. We might need to eventually filter on the server side but there are performant JS libraries that should be enough for our purposes.
We can assume that when a user views one image full screen, they are quite likely to also go to the next or previous photo too. We might also say that the user is likely to click on the first image when they have filtered or selected an album. If a user hovers over a thumbnail, they are likely to click it. We could download these images ahead of time so the server has started to generate the scaled images and the browser has them in the cache ready. We should be aware of extra bandwidth usage, especially on mobile devices.
This could be inserted by mounting a Docker volume to a file that then gets included. The use cases are for things like custom CSS styling and analytics.
I noticed that object detection stopped working on the demo site. It appears the Redis lock that prevents multiple workers downloading at once prevented any workers from downloading.
Currently the map doesn't pan or zoom automatically to where the photos are. It should present all the filtered photos on the map, zoomed in as much as possible. This should change while user is changing filters and the list of photos reduces or expands.
Detail view of photo showing camera attributes, tags, mini map, bounding boxes from object detection.
Modal view of photo which is on a higher z-index so main UI doesn't get redrawn on close.
Scroll down to see more details with animated indicator on first display and when hovering near bottom (no scroll bar will be displayed as we want photo to be as full screen as possible).
Scrolling down should make new pane float over photo without the photo moving - the pane might not be very tall and could control photo overlays such a bounding boxes. Make touch screen compatible too.
Location map and pin defaulting to a sensible zoom level
Colors display
Styles display
Camera settings display
Cross icon and ESC key to close modal
Star rating
Histogram
Full metadata display from exif
File path/name display
Move metadata overlay to be on the right with an icon to view it as scrolling down is not obvious
I've installed Photo Manager to my localhost:8888 and have the thumbnail images with all the current filters working to narrow down the images shown. If I click an image though, it takes me to a random url (different for each photo) which is just a plain black page, so I cannot view my photos enlarged.
It would be helpful to scroll back to a particular month/year when trying to use the main scroll bar. This could incorporate a histogram of number of photos taken each month. It might display when you hover over the right-hand area of the screen or when you start dragging. Need to also consider how it would display on touch devices that don't have hover events.
Sections of photos to jump to
Histogram display next to scrollbar with clickable bar per section
DOM sizing based on known sections and images within
Scroll spying to populate and unknown sections that are close to the viewport
If a user uploads a raw photo, we will need a JPEG generated of it at full size so we can use it as a source to generate all other thumbnails. There might already be a JPEG with the same timestamp/number but we can't be sure that it was generated by the camera or by program at a later date. dcraw might be able to process all the raw formats we need but it could take a bit of tweaking to get acceptable results. A notice will display when viewing the "raw" in detail explaining that we generated the image to be helpful. The processed resulting JPEG should be stored separately from the main photo collection as we don't want to pollute the user's photo folder.
AC:
Raw photo processing for a test set of images from different cameras
New folder for raw-processed
Raw to JPEG conversion that happens via task processing queue
Parallel processing
Processed JPEG should have PhotoFile.id as the filename
Store the method, our own version number, dcraw version number etc. on PhotoFile instance so we can re-process if we discover a better technique later on.
Thumbnailer should check the new folder location if PhotoFile has been raw processed
Maybe TIFF and PNG files should be processed in a similar manner.