News for hackers. Stuff that matters.
Re:How Retroactive makes Aperture, iPhoto, and iTunes work a... by jwr on Tuesday March 03, 2020 @03:48AM (#22472908)
After I got royally screwed by Apple discontinuing Aperture (I mean, come on, it's not like they're google or something), I decided to a) package Aperture in a VMware virtual machine so that I don't lose access to my libraries and b) start working on my own software for long-term photo archives.

The project you are describing sounds close to my goals, with the possible exception of long-term storage: I've been planning to develop everything so that data is easily retrievable even if the software doesn't work. Metadata in text files, for example, image storage in well-known formats, folder structure that is understandable to humans, etc. This is for family archives: I'm scanning photos that are a hundred years old and I feel like an idiot when cataloging them using software that some company will obsolete in a couple of years.

Incidentally, there is another niche which is largely unaddressed: easy organizing of photos into sets with various access tags and sharing these with friends and family in a secure and easy way. It's kind-of doable today if you don't care about privacy, security, and longevity, but it's still annoyingly difficult to use, especially for less computer-literate family members. It seems that all designers of photo software only keep photos from their latest vacation, wipe their entire collection with each device upgrade, and want sharing links to be valid for at most a month or so.

One thing which could prevent me from using your software is lack of control: I got burned several times already and I'm considering my options carefully. It might be better to roll my own rather than start depending on something again.

Re:How Retroactive makes Aperture, iPhoto, and iTunes work a... by mceachen on Tuesday March 03, 2020 @12:49PM (#22476851)
I've made a bunch of design decisions to address long-term storage concerns (after being personally burned by more than a handful of abandoned photo apps):

File storage (if you opt for PhotoStructure doing automatic organization) is configurable (with a default of $library/yyyy/yyyy-mm-dd/$original-filename).

All metadata extracted or changed is saved in standard-format sidecars next to the original, or in the image itself. The sidecar format and whether to use sidecars for edits are both configurable.

The database is a SQLite DB with a straightforward schema (although as I add features, each version has had db migrations).

If you try PhotoStructure out, and you find or think of anything else I can do to set things up to be more friendly to long-term storage, I'd love to hear your ideas.

(Sharing is coming in a future release, both via any hierarchical tag, or by manually-selected images).

Re:How Retroactive makes Aperture, iPhoto, and iTunes work a... by jwr on Wednesday March 04, 2020 @05:16AM (#22482561)
Everything you wrote is very intriguing and largely aligned with my goals. I'd like to take a closer look at what you are building.

There is still the issue of control: I am worried about the lack of a "Pricing" page, not because I do not want to pay (quite the opposite), but because I am worried about the sustainability of your business. And about what will happen when you sell it to Google, or otherwise abandon it.

Re:How Retroactive makes Aperture, iPhoto, and iTunes work a... by mceachen on Tuesday March 03, 2020 @03:17PM (#22478339)
> scanning photos that are a hundred years old

FWIW I've got a bunch of both scanned images and older JPGs that I inadvertently stripped all metadata from (if you use jpegtran to losslessly rotate, make sure you use `-copy`!), so PhotoStructure infers captured-at time from filenames or enclosing folder names if it's missing from the EXIF headers, and it can extract at least a reasonable year, month, and day from the path.