Why are stack-sources not saved in the afphoto document?

[Ravn]

One of the main incentives for me to buy AP was it's excellent focus-stacking and panorama stitching. But with the sources not being saved into the document make it sort half useless. If I wanted to change anything in a stack at a later point, I would have to start the process all over again. That is a bit (more than) annoying.

I can't see any reason why it's not there? Yes the document could potentially become extremely large, but that is easily remedied by a) making it optional, b) having an option to save as references instead of into the actual afphoto document.

I sincerely hope this is something being considered. Personally, I consider the current implementation as a serious flaw

[John Rostron]

I would agree with you. However you are more likely to get a response if you repost your message in the Feedback for Affinity Photo on Desktop forum.

John

[walt.farrell]

2 minutes ago, John Rostron said:

However you are more likely to get a response if you repost your message in the Feedback for Affinity Photo on Desktop forum.

Serif is more likely to respond here, I think, as they generally do not respond in the Feedback forum.

However, the Feedback forum is where they look for requests to change the behavior, so posting there is definitely the right thing to do. Perhaps a moderator will move this thread over there.

Welcome to the Serif Affinity forums, @Ravn.

[Ravn]

Thank you both, @John Rostron and @walt.farrell, for the replies. I haven't quite gotten my bearings around this forum yet.

I'll give it a day more, and if I don't get more attention here I'll post in the Feeadback Forum as well.

[kirkt]

Depending upon the size and bit depth of the images, and how many you want to stack to get your final output, you can imagine that the file size of the resulting .aphoto file that includes all of the source images would be unmanageable for many systems running AP.  An alternative might be one in which the user put all of the source files in a folder and AP loaded those source images into a stack and then produced XML instructions that recorded the alignment and segmentation of the sources.  The XML instructions could be included in the .aphoto file, or as a sidecar - either way, the source images would be LINKED to the .aphoto file, not EMBEDDED.  If you needed to go back and make edits, you could invoke the "Edit stack..." button that does not yet exist, and the XML instructions would reload the original source images and alignment and segmentation/depth map for you to tweak accordingly.  This would essentially make the workflow non-destructive to the source images.

The same thing could be implemented with the HDR Merge and the Panorama modules as well, effectively creating a semi-Smart Object like workflow without creating an enormous .aphoto file.  This approach would require keeping the .aphoto file and its XML instructions linked to the source files.  If the link is broken (maybe you moved the source files somewhere else) then a prompt when loading the .aphoto file to locate the source files could pop-up, for example.

You could also have an option to EMBED the source images too, if you do not mind the potentially large file size.

Kirk

[walt.farrell]

45 minutes ago, kirkt said:

Depending upon the size and bit depth of the images, and how many you want to stack to get your final output, you can imagine that the file size of the resulting .aphoto file that includes all of the source images would be unmanageable for many systems running AP.  

Ravn mentioned that , and another solution: save referenced to the source images, not the actual images. Then, as long as the images weren't modified or moved or renamed the stack could be recreated with very little extra space needed.

In a way that's perhaps a variant of your XML instructions idea.

 

[thomaso]

On 10/5/2020 at 2:01 AM, Ravn said:

Yes the document could potentially become extremely large, but that is easily remedied by a) making it optional, b) having an option to save as references instead of into the actual afphoto document.

Agree! Another workflow could maintain the original images as masked layers, with the option to discard these additional pixels before saving.

But most appealing is the feature of linked images ('as reference'). Would be useful also for other workflows, in particular for RAW development which currently can not get changed once the confirm button was pressed.