Home > snap

snap

Snap is a project mainly written in VALA and RUBY, based on the GPL-2.0 license.

The simple photo workflow manager

Download

Snap: Simple photo management

Snap aims to be very good at a single thing: helping you with your digital photo management workflow. It won't feature red-eye removal, one-touch image enhancement, or any other neato gimmicks. It just provides a clean and easy interface for organizing your photos. Snap wants to get out of your way and leave the heavy lifting to more specialized applications. If it is doing its job, you won't spend very much of your time using Snap at all.

Implementation Priorities

v1.0:

  • select a "photo directory"
  • import photos into a date-ordered tree in the above photo directory
  • stick NEFs into a parallel tree, named identically to their partner JPG
  • create thumbnails of said images, after import, and place them into a similar tree
  • ability to browse the photos
    • basic scrolling ability (LTR slider, no pretty graphics)
  • ability to delete unwanted photos from the browse window
    • one "delete JPG" action (better to use the less-specific "derived" or "low-res")
    • one "delete NEF" action (better to use the less-specific "raw" or "hi-res")
    • one "delete both" action
  • lossless rotation
    • reload thumbnail and photo after rotation
  • ability to differentiate between photos that have NEFs and those that don't
    • perhaps the borders around the photos?
    • better yet, a star or some other emblem on the corner of the photo (film roll emblem!)
  • ability to tag photos from the browse window
    • have a tag bar on the side, w/check boxes to indicate if selected photo (or photos) is (are) tagged
    • all tags to JPGs transparently apply to NEFs, too
  • ability to create tags
  • ability to delete tags
  • ability to rename tags
  • image view w/ability to tag (or just zoom image to fill thumbnail area)

v2.0+:

  • ability to select multiple photos
  • pretty 2-level timeline slider for navigating through time
  • ability to search by tags, metadata, etc.
  • ability to reorder tags
  • open photo (and/or NEF) in external program
  • import dialog allows user to select which photos (including "all") to import
  • user can change the thumbnail size in the various views
  • has default values on import for artist, copyright, etc.
  • allows the user to edit some EXIF/IPTC/XMP fields on a per-image basis

Desired features

  • arbitrary tagging support
    • enables any kind of workflow
    • fixed tags can be dropped onto images from a "tag bar" on one side
    • the tag list can be reordered (it is rank ordered by default, by frequency of use if the user doesn't specify an order)
    • the tag list can have a scroll bar once it grows beyond a usable height
    • tags can be assigned a color (defaults to semi-random color distribution scheme)
  • implicit tagging support
    • the app will tag if the user has "seen" this photo before, thereby sensing new image additions by their absence of this tag
    • various statistics can be generated and added/edited as tags (# times viewed, etc)
  • tag view (only photos with a given tag(s) are shown... see search view)
  • calendar view (heat-mapped calendar widget, pale blue -> bright red?), probably implemented on top of the search API
    • should be implemented as a scroll widget on top, a la F-Spot or the Timeline JS library (max length of bottom "year" band = 5 years or something manageable)
  • zoom view (zooms an image in the existing view to almost -- but not quite -- the full window, allowing the dragging of tags onto the image (like image view, but not in a separate window)
  • image view (a single image)
    • a summary pane with tag & EXIF information displayed
    • right and left navigation
    • fullscreen button
    • slideshow (optional)
    • GPS coords on a map?!
  • search view (search by tag, file name, date, metadata, etc.)
  • remove tag(s) (removes the given tags from the selected items)
  • remove image (deletes the image, with a little sanity dialog)
  • rubber band select & ctrl+a select
  • lossless rotate!
  • delete file (prompts if a RAW file with the same name exists)
  • delete just attached RAW file
  • open file in other program
  • open attached RAW files in other program (def: Gimp or other RAW editor)
  • date-ordered tree (files are named YYYYMMDDhhmmssxx.[jpeg,jpg,nef,???] and live in a directory like YYYY/MM/DD/[file])
  • import dialog allows user to select which photos (including "all") to import
  • user can change the thumbnail size in the various views
  • has default values on import for artist, copyright, etc.
  • allows the user to edit some EXIF/IPTC/XMP fields on a per-image basis

Implementation ideas

  • file import ties into gvfs-gphoto2-volume-monitor
  • Tracker for tags, search, etc
  • Vala with minimal dependencies for simplicity and maintainability
  • design UI w/Marijana's heavy input
  • write API first
    • have separate daemons for long-running processes that are launched on client request
      • import daemon
      • rotate daemon
      • delete daemon
      • tag daemon (add and remove)
  • look into XMP metadata (the exempi library can be wrapped)
    • the application will look in the XMP payload to read & write tags, but they will need to be synched with the underlying EXIF & IPTC tags to be 100% portable (exempi seems to do this!)
  • when a photo is opened for editing in another application, silently copy the file to _.jpg, then launch the external editor on that file
    • spawn a daemon to watch for changes to the file
    • edit the file's XMP data (xmpMM tags) to track the history of the file (its parents, last edit, etc)
    • use the xmpMM data to construct file histories/family trees (need good graphing library!)
  • each photo has the tags embedded into its EXIF metadata
    • use Exif.Photo.UserComment for Tracker support (NO! Not anymore!)
    • use Iptc.Application2.Keywords for other application support, and because it's the Right Thing (call Tracker.Metadata.Set to make sure Tracker knows about it)
    • naw... just use XMP (exempi) for everything: it's righter and easier
  • for basic EXIF data, perhaps use libtiff for extraction, where exempi might be insufficient
  • look into libopenraw for NEF support
  • for unified EXIF/IPTC/XMP + thumbnail extraction, exiv2 sounds perfect (but it's in C++... which blows)
  • GStreamer seems to also have support for tags, but possibly only for reading...
  • extract the thumb from the image, if possible (exiv2 -ep1 )
  • focus on SPEED! (import, navigation, search, etc)
  • if the object model & API are well-designed, consider embedding Gjs or SEED for workflow scripting & plugins
  • to display maps, look into libchamplain

EXIF/IPTC/XMP tags with read/write support

see: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html see: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html see: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html

  • EXIF:Author
  • EXIF:Copyright
  • EXIF:ImageDescription
  • EXIF:UserComment
  • EXIF:Annotations?
  • EXIF:Rating
  • EXIF:GpsInfo
  • EXIF:PreviewApplicationName
  • EXIF:PreviewApplicationVersion
  • IPTC:Category
  • IPTC:Keywords
  • IPTC:Headline
  • IPTC:Credit
  • IPTC:Source
  • IPTC:CopyrightNotice
  • IPTC:Contact
  • IPTC:Caption-Abstract (2000 character limit)
  • IPTC:LocalCaption
  • IPTC:DocumentNotes (1024 character limit)
  • XMP:cc namespace (all Creative Commons tags)
  • XMP:dc namespace (all Dublin Core tags)
  • XMP.dc.artist
  • XMP.dc.rights
  • XMP.dc.title
  • XMP.dc.description
  • XMP.dc.subject (for tags!)
  • XMP:exif namespace (ideally, these would be synched with EXIF tags)
  • XMP:iptc4xmpCore namespace (all IPTC tags)
  • XMP:iptc4xmpExt namespace (IPTC editing & context tags)
  • XMP:xmp:Advisory
  • XMP:xmp:BaseUrl
  • XMP:xmp:Label (for tags?!)
  • XMP:xmp:Rating
  • XMP:xmpRights namespace

Inspiration

  • jbrout (http://jbrout.python-hosting.com/)
  • niepce
Previous：li2mod

©2024 OSPHUB.COM