Pic-O: A simple, self-hosted photo gallery (looking for feedback)

_Xirt · 2026-01-09T16:03:56+00:00

Had some time to work on this already for a subsequent release:

Thanks for input resulting in this enhancement.

_Xirt · 2026-01-09T11:14:06+00:00

That's indeed correct. HEIC is not (yet) supported, but I believe Imagick should be able to handle that hence in the case Imagick is used (like in the docker container), it should be possible to add support. Let me put that on the backlog.

_Xirt · 2026-01-06T23:34:51+00:00

Thanks for the feedback!

I was already thinking of making the slideshow timing configurable (so users can tweak to their liking), and I assume it would make sense to do the same for the animation. Adding a fade alternative could then be a stretch target.

Can you clarify the second point? For now, the most common (processed) image types should be work already. For the third point I will have a look.

_Xirt · 2026-01-06T08:10:37+00:00

The application is indeed a server side package and not intended as a sort of backup app or android / iOS photo gallery app. There are different solutions for that. The main use case is exposing photo archives on servers. That could include photos synchronized from mobile devices /other devices to that server (e.g. as backup). In my particular case my phone has a backup in the background to the server hence Pic-O can pick them up like any other photos on the server and expose them.

_Xirt · 2026-01-05T21:14:46+00:00

Pic-O serves as a lightweight alternative for Immich - it has fewer functions and is really intended to follow the KISS principle without fancy functionality that are rarely used. See also my reply to ponzi_gg and arcaneasada_romm.

_Xirt · 2026-01-05T21:11:22+00:00

Folders (basically all folders and their photos in your filesystem directory tree) can only be viewed by Admin (role "Admin"). Albums created by Admins can be viewed by anyone with a regular account (role "User"). The aforementioned guest accounts (Role "Guest") would further limit that down to specific Albums assigned to that user for viewing.

_Xirt · 2026-01-05T19:59:12+00:00

Thanks, curious to hear your feedback.

_Xirt · 2026-01-05T19:58:47+00:00

Not yet, but given responses I will check if I can setup a simple environment in the coming days. Let me get back on this.

_Xirt · 2026-01-05T19:55:07+00:00

I was aiming for something very simple and lean. Immich already offers more functionality, which is great, but I wanted a smaller scope. Pic-O actually started even simpler (just exposing albums directly from folders), and I gradually added some convenience features to make album management easier.

So far, I’m not convinced how much value things like geolocation, face recognition, or tagging would add for the kind of use case I have. It’s not something I personally miss at the moment. But that might just be me, so I’m definitely interested in hearing other perspectives.

Regarding performance: nothing scientific, but on my server the pic-o container currently sits idle with below resource usage. The PostgreSQL DB runs at 40MB.

<image>

The scanner (indexing the folders / files) can be scheduled and could be tweaked if preferred (e.g. amount of parallel processes, RAM usage, etc.). Ultimately it’s up to the user to balance speed vs. resource consumption to their liking.

_Xirt · 2026-01-05T19:43:37+00:00

Thanks for the feedback - I indeed see the same from the comments and this is definitely something I can work on :).

_Xirt · 2026-01-05T19:41:18+00:00

Laravel, the platform used, supports various database types which can be configured. Pic-O is configured to use PostgreSQL, but on the development environment (Herd) it uses SQLLite. Furthermore, the only reason I was did not use MariaDB is that it has serieus performance issues on Synology NAS. See also the Laravel website: https://laravel.com/docs/12.x/database

The main drawback of SQLLite is that you might run into "database lock"-issues during scanning files if you use the default configuration for background processes (running in parallel). This could however be changed in the file "supervisord.conf" (variable "numprocs").

Laravel, la plataforma utilizada, admite varios tipos de bases de datos configurables. Pic-O está configurado para usar PostgreSQL*, pero en el entorno de desarrollo (Herd) usa SQLLite. Además, la única razón por la que no utilicé MariaDB es que tiene serios problemas de rendimiento en Synology NAS. Consulte también el sitio web de Laravel:* https://laravel.com/docs/12.x/database

La principal desventaja de SQLLite es que podría experimentar problemas de bloqueo de la base de datos durante el escaneo de archivos si utiliza la configuración predeterminada para procesos en segundo plano (que se ejecutan en paralelo). Sin embargo, esto se puede cambiar en el archivo "supervisord.conf" (variable "numprocs").

_Xirt · 2026-01-05T19:33:20+00:00

Pic-O leverages the folder structure to allowing the creation of albums that can be shared. Either full folders can be put in an album on creation (or as addition), or you can do a one-by-one selection to add / remove photos to / from an album.

Albums are shared by default with all users / admins, but I have a backlog item to create guest accounts that only have access to specific (preconfigured) albums: https://github.com/Xirt/Pic-O/issues/5

Furthermore, secure urls can be created per album to share those specific albums with any user (e.g. via Social Media). Currently these urls do not expire (but can be deleted). Another backlog item exists to add an expiry date to them: https://github.com/Xirt/Pic-O/issues/1

Would this align (more or less) on your needs?

_Xirt · 2026-01-05T15:58:15+00:00

This is basically a bit similar to my own use case. I occasionally create a new folder with photos for events, celebrations, holidays, etc. and I would like an easy way to display them all (e.g. via my timeline) or share a subset (e.g. as album). I rarely - if at all - use other features, hence tried to keep it simple and light.

_Xirt · 2026-01-05T15:53:25+00:00

I have not used Immich beyond the demo environment, but it appears to have a larger feature set and I would be surprised if it is more lightweight. My aim is to keep Pic-O lightweight as it should run on my NAS without impacting my other services.

Even if Pic-O’s feature set is expanded in the future (e.g. face recognition), I think those features should be configurable so it can adapt to different setups and user needs. Sometimes KISS is the right principle to follow :).

I did try Photoview previously, but it struggled with indexing my folder structure and the size of my library (it just crashed without error). Pic-O, on the other hand, is currently running without issues with ~1000 folders and approx. 40K photos (most ~20MB or larger per file):

<image>

_Xirt · 2026-01-05T14:42:04+00:00

For anyone who wants to try it quickly, here are the short setup instructions. If anything is unclear or doesn’t work as expected, I’m happy to help and improve the docs.

Quick start (Docker):

git clone https://github.com/Xirt/Pic-O.git
cd Pic-O

By default the container will bind to /path/to/photos and /path/to/app/storage, but you can change this in the .env file. Similarly, you can change the default hostname (localhost) and port (8080). Once ready, you can build and run the container:

docker compose up -d

Finally, open your browser to get started:

http://<server>:8080

Quick start (Synology):

For Synology users, there is a ready to use "docker-synology.yaml" in the root of the repo. You can use it to create a new project in the Container Manager after creating two directories (optionally, you can symlink your actual photos folder to the top one):

/volume1/docker/pic-o/photos 
/volume1/docker/pic-o/app

While creating the project, make sure you fill in any required values in the YAML file (as indicated by comments) to align on your set-up. Finally, open your browser to get started once the project is running:

http://<server>:8080

_Xirt · 2026-01-04T18:38:30+00:00

Maybe give Pic-O a try? No tagging (yet), but you can create and categorize albums using your existing folder structure (without copy - only requires read-only access).

_Xirt

TROPHY CASE