Please add a warning when "save" will overwrite the original source image

[kbuzsaki]

Normally when using Affinity Photo there are two options for producing output files:

1. "Save" / "Save As" which will produce a .afphoto file
2. "Export" which will produce any of about a dozen different output formats like .jpg, .png, etc.

My intuition is that the former will be "lossless" and will not destructively update any of my source images since it is in the native format, while the latter will likely be lossy and can potentially overwrite source images if I use the same filename.

In Affinity Photo it seems that this intuition is almost true, with one crucial and surprising exception: if you "open" a single source image directly and then make simple changes to it (e.g. cropping, auto-white balance), then "Save" will not produce a .afphoto file and will instead destructively update the source image. This is inconsistent with the behavior when starting from a blank canvas and as someone who comes from GIMP and is used to the "save" vs "export" distinction, I found it extremely surprising. I almost lost data because of it but was fortunate that I had a backup of the image elsewhere.

Please help me and other users avoid making this mistake by adding a warning to confirm that you want to destructively overwrite the source image when you "save", similar to the warning that you get when you export using a filename that already exists. Having an option to enable the warning would also be fine.

I understand that for some users the current behavior is convenient because it lets you quickly make minor edits, and that there are workarounds like being vigilant and always immediately using "Save As" when you open from a source image file in order to fork it to a .afphoto file, but I don't think those are good enough justifications for having this "footgun" around that can cause users to accidentally lose data when they do something as simple and reflexive as save their work.

[Dan C]

Hi @kbuzsaki,

Welcome to the Affinity Forums

18 hours ago, kbuzsaki said:

if you "open" a single source image directly and then make simple changes to it (e.g. cropping, auto-white balance), then "Save" will not produce a .afphoto file and will instead destructively update the source image.

I would expected you should see the below dialog appear when following this workflow, for example this was shown after opening a .JPEG file and applying an Adjustment layer, then using File > Save -

Here, selecting 'Save Flattened' would overwrite the original JPEG file, and Save As would create a new .afphoto file.

If you're not seeing this dialog currently, could you please confirm for me, are you using Affinity on Windows, macOS or iPadOS?

If possible, could you provide a screen recording of your workflow so I can better understand a potential reason for this warning not to show?

Many thanks in advance!

[Return]

The OP is right, the destructive filters will overwrite on save without any notice.
Tried with what the OP said here cropping ,auto white balance all without a notice.

[Return]

Perhaps a "file is modified" notice should be present on save/ctrl+s when there's a history step added and where the file get's the modified tag  on the tab.
Like it is on ctrl+w

[Dan C]

My apologies, I had missed the 'auto' part of OPs post and had tested using a White Balance filter - if there are additional layers in the file after opening and editing, this warning will appear when saving.

If you have only destructively edited the imported Pixel layer, then this warning will not be shown upon saving.

As far as I'm aware this is By Design currently - though I will be sure to check this with the team, and if so this stands as a valid request for improvement

[Andy.Orange]

So, 16 months later, what happened to the "valid request for improvement". Surely, this would be simple to implement, and has been requested more than once.

[walt.farrell]

1 hour ago, Andy.Orange said:

So, 16 months later, what happened to the "valid request for improvement". Surely, this would be simple to implement, and has been requested more than once.

The QA and Support teams can create improvement requests, but the Developers or planners decide what gets implemented, and the priorities.  They're also the only ones who know how simple or complex something would be to implement.

[Evaluation complete.]

This is fairly common behavior in this case. I've opened many files in different image editing programs, cropped them, and saved with Control-S. I don’t recall ever seeing a confirmation prompt. I can also remember accidentally doing it and causing damage, so I fully understand if SOME people would want an "always ask for confirmation" preference. 

This applies generally to all software: saving is the direct way to quickly save changes without a prompt, and it’s through routine use of saving that many have avoided losing data during software crashes. Should it prompt every time you press save? After all, you’re making destructive changes every time you modify pixels.

Photoshop doesn’t ask for confirmation either, though with the slight difference that if Photoshop cannot detect in the image metadata that the image has been saved in Photoshop before, it prompts you to confirm or adjust the compression level.

Quote

but I don't think those are good enough justifications for having this "footgun" around that can cause users to accidentally lose data when they do something as simple and reflexive as save their work.

We can’t turn the world into a padded cell where everyone is protected from everything that could go wrong. You can just as easily accidentally click "Yes" in that dialog anyway, as I’ve seen countless times in the opposite scenario with "Save changes? There are unsaved changes since the last save," where people accidentally hit "No."

The ultimate best solution is periodic backups with versioned copies of files. This allows you to revert to older versions of documents - before you rewrote a section and later regretted it, before overwriting a JPG file, before losing something in a crash, or before cleaning up and deleting too much.

And infinitely better than designing software to handle everything as if it were nitroglycerin.

[fde101]

3 hours ago, Andy.Orange said:

So, 16 months later, what happened to the "valid request for improvement". Surely, this would be simple to implement, and has been requested more than once.

Just because you ask for something doesn't mean it will be granted.  You asked, the answer may very well be "no".

The current behavior is logical and expected for this kind of application, so it is questionable whether or not everyone would consider this an improvement - many may be annoyed by the extra prompt they need to go through for something they used to do without one.

[Pšenda]

15 hours ago, Ingelise said:

This is fairly common behavior in this case. I've opened many files in different image editing programs, cropped them, and saved with Control-S. I don’t recall ever seeing a confirmation prompt.

I recommend reading the opening post carefully again, because this is a completely different case. The OP does not ask for a prompt (warning against overwriting the original) if you open a native affinity file, and use Save to overwrite it - because that is of course a common and obvious thing for all users, but about a warning against overwriting if you open a JPEG/TIFF/PNG, which under normal conditions, as declared in the Help, you cannot save like this - you have to export it.

Related topic:

[Return]

53 minutes ago, Pšenda said:

if you open a JPEG/TIFF/PNG, which under normal conditions, as declared in the Help, you cannot save like this - you have to export it.

Yes you can use save for these and afaik was always the case, even in version1.
So that warning should be in place for just raster images opened directly.

 

 

[Pšenda]

4 hours ago, Return said:

So that warning should be in place for just raster images opened directly.

Of course - that's how it was always thought and described in the posts. It was never about the general Save command - that is, if I open and save the native affinity format. The proposed measure with a warning using the Don't Ask dialog, which Serif already uses - so it doesn't require any new programming, and which allows informed and knowledgeable users to immediately turn off the warning, is a very easy solution. At the same time, it draws the user's attention to the inconsistency of the behavior explicitly stated in the Help, that is, that using save only saves to the native format, which is not true in this case.

[Evaluation complete.]

10 hours ago, Pšenda said:

I recommend reading the opening post carefully again, because this is a completely different case. The OP does not ask for a prompt (warning against overwriting the original) if you open a native affinity file, and use Save to overwrite it - because that is of course a common and obvious thing for all users, but about a warning against overwriting if you open a JPEG/TIFF/PNG, which under normal conditions, as declared in the Help, you cannot save like this - you have to export it.

That is exactly the scenario I’m talking about. Open the JPG directly in Photo/Photoshop, crop, whatever, save, done. No confirmation needed, because it’s completely normal to work directly with JPG, PNG, or TIFF files without saving in PSD/.afphoto formats. Doing so is an entirely unnecessary step in many, many workflows and would leave drives cluttered with native .afphoto or PSD files of all sorts, especially when you’re not working with layers or advanced features like those in PSD/.afphoto files.

I understand that some people might need this safety net, but it absolutely should not be forced onto experienced and professional users who have complete control over their workflows and are fully aware of the minor risks involved - risks that are also present in countless other scenarios with other types of software when saving directly.

There must be consistency between the program's behavior and the customers' workflows as the top priority.

[Pšenda]

21 hours ago, Ingelise said:

I understand that some people might need this safety net, but it absolutely should not be forced onto experienced and professional users

That's why there has been a proposal for a Don'tAsk dialog for several years, so that for an experienced user it's a matter of one single click, and they'll never see this warning (a safety net) again. Interestingly, Serif has already implemented the same "safety net" method when opening a Legacy document, where inexperienced users are informed about the incompatibility of the new document, and experienced users simply turn off the message.