Support multiple operations on one image.

[derei]

Currently, only one operation can be performed (eg. crop), after which, the file must be saved to not lose the changes. Then, if another operation is required, the image must be loaded again, and so on.

There are few issues with this workflow:

• is tedious and unproductive
• multiple saves for any lossy file format will unavoidably lead to considerable quality degradation
• difficult to keep track, or undo changes

It would be nice to be able to perform any number of operations of edits on an image, and when done, to only save once.

Take for example Snapseed. Yes, is a Google app, but I'm only offering it as an example for the mentioned workflow.

[T8RIN]

You can share the image back to the ImageToolbox and continue operations, and go back to see the previous step now :)

[derei]

You can share the image back to the ImageToolbox and continue operations, and go back to see the previous step now :)

You mean, after is being saved once the operation had been completed?

If this is what you mean, then it falls under one of the downsides mentioned: the image quality will degrade with each save. Even setting a .jpg quality to 100%, is still lossy, just with minimum amount of degradation, but ridiculously large file size 😄.

[T8RIN]

Kinda, but without saving, directly sharing

[T8RIN]

You can use single edit also for 4 basic operations without saving or sharing

[derei]

Kinda, but without saving, directly sharing
I just tried what you suggested. Yes, it's a workaround... and it works.

However, the android native share feature requires the file to be saved temporarily, because it relies on URI path to share data. And doing this operation several times, it will cause significant degradation, depending on image, initial conditions, operations performed, etc.

Jpeg compression doesn't only cause additive loss of quality (cumulated loss of information through discarding), but also transformative (introduces new artifacts with each save), which can make the next save even more lossy.

I believe that a better way of dealing with multiple edits is to work with the data already in RAM, and only perform one save at the end.

This would also allow to return to previous edits. For example: I crop an image, and after that I apply a filter, or watermark. Then, I decide to adjust crop, so I go back to the cropping tool, I readjust the boundaries, then , depending on other edits applied, some could readjust automatically (filters, watermark), and others may require further manual intervention (for example background removal).

But I'm digressing. The above example was just to emphasize the potential advantages of processing the image from memory, rather than having intermediate saves, which not only add compound degradation, but also can't alter applied edits.

[derei]

You can use single edit also for 4 basic operations without saving or sharing

Yes, thank you, I could see that. Could it be extended to all types of edits?

[T8RIN]

i will look, i think something could be added also

[T8RIN]

Kinda, but without saving, directly sharing
I just tried what you suggested. Yes, it's a workaround... and it works.

However, the android native share feature requires the file to be saved temporarily, because it relies on URI path to share data. And doing this operation several times, it will cause significant degradation, depending on image, initial conditions, operations performed, etc.

Jpeg compression doesn't only cause additive loss of quality (cumulated loss of information through discarding), but also transformative (introduces new artifacts with each save), which can make the next save even more lossy.

I believe that a better way of dealing with multiple edits is to work with the data already in RAM, and only perform one save at the end.

This would also allow to return to previous edits. For example: I crop an image, and after that I apply a filter, or watermark. Then, I decide to adjust crop, so I go back to the cropping tool, I readjust the boundaries, then , depending on other edits applied, some could readjust automatically (filters, watermark), and others may require further manual intervention (for example background removal).

But I'm digressing. The above example was just to emphasize the potential advantages of processing the image from memory, rather than having intermediate saves, which not only add compound degradation, but also can't alter applied edits.

You can use bmp for sharing, it's just raw image without compression

[T8RIN]

This added as share -> edit