I am thinking of adding support for Picasa metadata.

[lancerushing]

First, Thanks for a the great importer!!! (Just started using immich.)

I do a little go programming, and I have a about 2TB worth of photos in a directory structure that we have in Picasa.

Picasa stores it's metadata (stars, descriptions, filters, etc) in a ".picasa.ini" file per directory.

I am planning on trying to add a parser for .picasa.ini this weekend to load descriptions and isFavorite, and I wanted to check in before I started.

1. first to avoid any duplicate efforts
2. get any suggestions on where you think it would fit into the upload processes (cmd/upload, cmd/picasa, helpers/, ??)
3. vet initial thoughts on implementation.

Initial thoughts:

• add a flag to turn on picasa support
• during directory scan, parse found picasa.ini into memory. hashmap probably, being careful with r/w concurrency
• during file parse/load, check hashmap, add matching description to "Metadata"
• if image has 4+ "stars" (configurable?) in picasa, mark as "IsFavorite"

Let me know if you have any suggestions. I'll probably start on it in a couple of days. I plan on doing a quick first pass, and then clean up with tests on the second pass.

Thank you again for a great tool.

-Lance

[simulot]

That's a great idea!
I haven't used picasa since a decade or so.

I'll need some picasa samples

[lancerushing]

I'm back working on this today. Just thought I'd update, and check for any input.

The file format for a .picasa.ini is something like:

[Picasa]
name=Name of Album
location=Mission Bay Park
date=38084.006597
P2category=Folders on Disk
description=A longer album description

[image-name.jpg]
star=yes
faces=rect64(7c7118a7ac166573),fbb549a7349d93eb;rect64(4b60342679997e1a),95745f57a138c4e7
backuphash=931
albums=a69213fd86eaf86a9efb18b412c70b0c,33d11064a5ba4959c16ec1adf070875c
filters=retouch=1;glow2=1,0.578947,4.275992;
moddate=0000efc206cd0000
width=3100
height=2256
textactive=0
caption=My Caption

[.album:a69213fd86eaf86a9efb18b412c70b0c]
name=Another Album
token=a69213fd86eaf86a9efb18b412c70b0c
date=2011-12-02T08:50:47-08:00

Every [section] and key=value is optional.

[lancerushing]

For my first pass, I plan on supporting

[Picasa]  # Directory level
name=Name of Album
location=Mission Bay Park
description=A longer album description

[image-name.jpg]
star=yes
caption=My Caption

If there is enough need, I might add support to the seconday [.album:<token>] in the future.

The "location" on the picasa album is a free form description string. (it is not coordinates). A plan on appending any location string to description. Example: A longer album description Location: Mission Bay Park

[lancerushing]

I used https://github.com/spf13/afero to abstract file system access. However, I noticed that github.com/psanford/memfs is being used in testgp_samples_test.go. Would you prefer to not to use https://github.com/spf13/afero? 🤔

[lancerushing]

I have a draft PR here: https://github.com/simulot/immich-go/pull/430/files

Everything is working: (I'm using it on my 80k image library) 🎉

There are a few things I want to add, but I wanted to get your input before I add too much polish.

1. Which pattern to use to inject the app.Picasa flag into localasset? Are you good with me add picasa bool to the signature of ExploreLocalFolder(ctx context.Context, fsyss []fs.FS) New: ExploreLocalFolder(ctx context.Context, fsyss []fs.FS, picasa bool)

2. I'll add more tests (especially upload_test.go)

3. I used github.com/spf13/afero to help with os.file abstraction. I noticed that we have github.com/psanford/memfs. I think afero is nicer, more active, etc. But it does have many more dependencies... 🤔

Do you want me to:
a) leave both in (doesn't mater)
b) convert the memfs code to afero
c) convert the afero code to memfs

Let me know, and I will get the code done.
-Lance

[simulot]

Thanks for your work.

Here are some informations on the design of immich-go:

The upload code is in charge of parsing the command options and opening a fs.FS for reading the source.
Doing so, the source could be a plain file system, a ZIP file, a collection of ZIP files, a mocked file system...

Afero was a thing before the fs.FS interface has been added to the library. I'm using memfs just for testing obscur parts of the code, the real code relies on an fs.FS implementation.

Your Picassa importer must implement the "browser.Browser" interface defined here:
https://github.com/simulot/immich-go/blob/1a4de53f812a58f7e4b312f5313552760570323e/browser/browser.go#L1C1-L10C2

Then the specialized "browser" is instantiated in the Upload code, like here:
https://github.com/simulot/immich-go/blob/1a4de53f812a58f7e4b312f5313552760570323e/cmd/upload/upload.go#L237C1-L245C1

Your importer type must implement the following methods:

• Prepare for an optional pass one
• Browse for the real upload

[lancerushing]

Thank you for the input. 🤔

Picasa stores the images on filesystem, in directories organized by the user. And the current app.ExploreLocalFolder browser works great for the images. I only need to add meta data from the .picasa.ini file in the directories.

I should move the package browser/picasa I created (b/c it isn't a browser). Two places I could move it to:
a) add the files into browser/files (makes it clear it is part of the files browser)
b) put the package in browser/files/picasa
c) maybe helpers/picasa

I think I'm leaning toward "c". Thoughts?

[simulot]

Your remark is valid... The scanning of a file system can be mutualized between all import methods, and keep separated the logic for the google photos, picasa, or a potential ICloud.

I guess this would simplify the work for contributors

[simulot]

By the way, the file scanning is pretty standard using the the standard library. That would make the thing overly complicated for managing differences between the different system.

So, I prefer to put all Picasa stuff into a the folder /browser/picasa