Browser-Based Uploads and Folder Management

[nielsfranke]

Currently, PICR is "read-only" regarding the file system. As noted in the documentation: "No files/folders are created or uploaded in PICR, you just put the files in that folder however you normally do."

While this works great for static home setups, it creates a bottleneck for professional "on-the-go" workflows. For example, when shooting events on location, I need to deliver photos quickly. Currently, this requires manual file management on the server/network level rather than a streamlined web-based workflow.

Describe the solution you'd like

I would like the ability to manage content directly through the PICR web interface. Specifically:

• Browser Uploads: A way to drag and drop or select image files to upload into an existing gallery.
• Folder Management: The ability to create new folders (galleries) directly from the dashboard.

Use Cases

• On-Location Delivery: Uploading selects immediately from a laptop or mobile device during an event without needing to access the underlying OS or network shares.
• Collaboration: Allowing a second shooter or assistant to contribute their photos to a specific gallery via the browser.

Proposed Implementation Details

Since this moves PICR from a read-only state to a write-enabled state, I suggest:

1. Admin Toggle: An option in the configuration to enable/disable uploads.
2. Authentication: Ensuring these actions are protected by the existing admin password/auth to prevent unauthorized users from modifying the file system.
3. Path Mapping: Uploaded files should be saved directly into the directory currently mapped to PICR.

[IsaacInsoll]

I'm happy to consider this as a new feature request.

It's not as high priority as a few other tasks like beautifying client delivery but it totally makes sense.

A few notes

• PICR defaults to read-only for media folder for maximum safety. But I already implemented "write mode" which requires you to set an ENV var and mount media folder with write access. Currently it only allows folder moves and renames but file uploads is a logical next step
• the two scenarios I can image are "users" (you or a second shooter who has a login) or "clients" such as a client uploading inspiration images or lots of guests at a wedding uploading candies. Let's develop "user uploads" first then if PICR users want it we can do "client uploads" which will be more user friendly and tailored for that scenario.
• should PICR allow uploads of any image format or just images? Currently you could have RAW files in a folder and allow users to download them but they wouldn't even see thumbnails in the gallery as only JPEG/TIFF/GIF/PNG are supported as Sharp (our image library) doesn't support every RAW format
• my wife does some social media work for clients so even just uploading JPEG or HEIF from mobile would be useful.
• app support would be great. Live activities on iOS would be goated

I won't even start work on this for a few weeks at least so this is very open to discussion.

[nielsfranke]

I personally don't need raw support, as I use lower resolution JPEGs for proofing and finally delivering edited photos also in JPEG or TIF. So JPEG/TIFF/GIF/PNG/HEIF would be enough for my use case.

If there's demand for basic RAW file support, a lightweight solution could be using embedded JPEG previews of RAW files. You'd need to add RAW file detection and a preview extraction step (for example exiftool) before passing data to sharp. This would be fast since you're just extracting an existing JPEG rather than processing RAW sensor data. Newer cameras generally follow the same JPEG extraction workflow, so you wouldn't need constant updates for basic preview extraction to keep working.

[tearsen]

I really like this idea and would definitely use it in my daily workflow.

For me it would be super helpful if “user uploads” could handle not only JPEG/TIFF/PNG/HEIF, but also the typical professional exchange formats like RAW, PSD and PSB. Quite often I’m working with retouchers or agencies and we exchange exactly these files, sometimes in both directions.

I don’t need full editing or heavy processing inside PICR. What would already be a huge win is being able to upload those files via the web UI in write mode and, just as importantly, having some kind of basic preview/thumbnail for them. Even a simple embedded JPEG from RAW files or a preview/composite from PSD/PSB would be totally fine. Without that, folders with these formats tend to look “broken” or unfinished for clients and collaborators, which isn’t ideal for a professional delivery platform.

If it helps at some point, I’m happy to test early builds on my NAS setup.

Thanks a lot for all the work you’re putting into PICR, I really appreciate it.

[IsaacInsoll]

Hi @tearsen would these retouches and agencies typically be users (login with a password) or links?

It's technically fine either way, I'm just trying to understand the workflow as much as I can. For example, me uploading a few images from my iPad or iPhone while on the go to my own PICR feels different to sending a link to a third-party where they can upload files and I get notifications as they come in.

Obviously once the file has been uploaded, it will be on your mouse in the file system like any other file and you will be able to comment, rate and all that stuff like any other file in PICR.

[tearsen]

For my usual workflow it’s almost always link-based, without creating user accounts.

In practice I send a gallery link to an agency, client, or retoucher and that’s it. Asking them to register, set up a user account, and manage passwords is usually too much friction, especially when people are just supposed to upload or exchange files quickly. So in most cases I prefer simple links.

I only really use proper user accounts when working on very sensitive or unreleased material, which is relatively rare for me.

As a side note: in the future, password-protected links could be a nice middle ground. That would add a bit of security without the full user/account overhead.

So overall: for me, uploads via secured links would fit best into my real-world workflow.

[IsaacInsoll]

Note: as per #56 I've allowed large files to still be processed (IE: generate thumbnails).
This is fine with the current system where all image uploads are trusted because if you upload a 300mb TIFF, or if you make a link for your client who does that, then it seems fine. But just something to consider if this ends up being more of a "anybody can upload anything" situation in future.