How to design non-destructive image editing with portals in mind

[sophie-h]

I'm currently working on non-destructive image editing in Loupe. This implies that I have to store the image editing history and the original images somewhere. I wanted to know how to best design this feature with (future) portals in mind to not require --filesystem=host access.

The current ideas for implementation are listed here https://gitlab.gnome.org/GNOME/loupe/-/issues/402

[swick]

Personal opinion: any system that requires multiple files to form a single thing is a horrible idea. We have that problem with html and svg files wanting to load resources from somewhere, with markdown files, etc. For markdown there is https://textbundle.org/ for example to bundle things into a single file. I expect that that's the only real workable solution for non-destructive image editing as well. I understand the problem of accidentally leaking information by sharing such an image but you already need specialized tooling to get rid of a other sensitive metadata from images. We should probably make sure those tools support whatever you come up with and maybe even integrate it in a future sharing portal.

[sophie-h]

We have that problem with html and svg files wanting to load resources from somewhere

Yes, that's the main reason I'm gathering feedback.

I expect that that's the only real workable solution for non-destructive image editing as well.

Note that Loupe needs extended access to the filesystem anyway since it can browse folders. I remember that we agreed that Loupe probably needs mime-type-based filesystem access anyway, so that might already cover accessing the original files.

[swick]

Sure, but I think those are orthogonal problems. If you don't store all information in that one file, users will copy only parts and wonder why something is wrong.

[hfiguiere]

There is an open issue to grant permissions to adjacent files. Just that no work has been done for that. It needs UX design and considerations, and also it isn't even a simple fix.

BTW modifying the original file isn't non-destructive editing. And to take it up to my domain, if you involve camera raw files, modifying said file to store some meta data ia a big no. That's why XMP (and other) sidecar files exists. That's what Darktable and RawTherapee do.

[sophie-h]

BTW modifying the original file isn't non-destructive editing.

Yes, I could try to pull off what JPEGXL does with JPG -> JXL conversion and save all the required information for restoring the original file. Not only is that hard for one file format, but we would have to do it for many file formats and invent our own standards for some of them. It sounds like an extremely fragile solution independent of the privacy issues.

That's what Darktable and RawTherapee do.

I guess they store it in the same folder under a different name?

[hfiguiere]

I guess they store it in the same folder under a different name?

That's what sidecar files are. RawTherapee stores a .pp3 file (proprietary g-keyfile like), Darktable a .xmp file (XMP). But they have larger concerns about file access.

[Mikenux]

Do you expect a portal including your case to communicate anything in particular to users?

[Mikenux]

We can probably opt for file backup if we want to tell users that we are preserving the originals or any final version of a file (i.e. when changes are written permanently to the file). This would then be a protective feature that we bring to flatpak/portals.

However, what is the changed file, i.e. the resulting file that the user is supposed to see in the file manager?