image is not updated when replacing an asset

That is expected behavior in the current version of Ansel. Ansel's saved image is a separate image generated from the original, but it is not the original. The element containing the field referencing the source image must be saved to generate a new image. Additionally, I'd also wonder if replacing the image retains the ID/relationship to the original image.

Not sure I understand the reasoning behind this? I do not want to give my users access to the ansel_high_qual folder, since this will add confusion. From the user's POV they edit an entry, add and crop an image in an Ansel field, and save the entry. If the user then subsequently decides to replace the original image via the asset browser, they see no change in the output of the template. If this is expected behaviour, what is the user expected to do in this case? If the user edits the entry containing the image, they will see the new image in the Ansel field, but the template output is still the old image. Re-saving the entry does not update the image, only after editing the cropping of the image, Ansel will regenerate the image files with the new image.

There are at least a dozen technical hurdles.

Firstly, you are quite right that the user should not have access to any folders or volumes designated for Ansel to store it's cropped images in.

As to the technical hurdles, here's the biggest, because the image was cropped just so, any new image uploaded could be anything. The image in any given field was uploaded, potentially cropped, resized, etc. Then an image is generated on element save based on that. A new image could be any size and the image the user worked so hard to get just right could be completely off.

I understand the technical challenge in that the user could upload a new image with different dimensions so the cropping wont be valid. However: · If the user chooses to replace an image with a new one with completely different dimensions, it is safe to assume that the user then has discarded the cropping and resizing they worked on getting just right with the original image, so this could simply be ignored. · If the user replaces an image with the same dimensions, the cropping could be recycled. In my experience this is a likely use case, because replacing an image in the asset browser is often useful when you have made some slight adjustment to color or similar, but the image is essentially the same.

In any case I still believe the current behaviour is the most confusing and least useful to the user. After replacing an image, the user will see the original image in the website and preview, but the new image in the asset browser and entry editor. Without knowing the inner workings of Ansel, and without access to the ansel_high_qual folder, the user has no way of knowing why the old image sticks and how to update it with the new image. In my opinion, simply resetting any cropping of the image and generating new Ansel assets would be preferable to this.

Another technical issue of course being that there's no way to know how many fields/elements this would affect and it could be a huge time consuming processes to regenerate all the images required.

In any event, I will keep this in mind as a potential future improvement.

O.k. - another related problem is that when you delete an image in the asset browser, it remains in the ansel fields. Perhaps less of a technical challenge to fix this, since it wont require any regenration of images.

That is also by design. What if a field requires at least one image and you delete a source image? Suddenly you would have an entry or element that has a field that requires an image but it's not there and template expects an image to be there because you've required it and did not code the template for it not to be there. Then a source image gets deleted and the site starts throwing 500 errors.

Currently, when a source image is deleted, any images in the fields associated with that image become "locked" meaning they can no longer be re-cropped or edited and can only be removed.

There is an additional, more serious issue with this:

1. Add an image to an Ansel field and save the entry.
2. Delete the image via the Asset browser.
3. Edit the entry containing the Ansel field with the image. Do not change the contents of the Ansel field containing the deleted image.
4. Save the entry.

This throws an "Imagine\Exception\RuntimeException" "Caused by: ImagickException" "The path is a directory"

Regarding you comment about the template expecting an image: The built-in asset field in Craft works like I described. Even if an asset field is marked "required", it is possible to delete the image it contains via the asset browser, and thereby getting an empty field. It is up to the template to check for this case. This behaviour makes much more sense to me, and since it is the default behaviour of Craft I believe it should set precedence for how plug-ins should behave. I also believe it makes more sense from a UX perspective.

I don't know any other way to stress that image Assets Ansel saves are not user serviceable. Source images are user serviceable, saved images from fields are not. Ansel expects to own that Asset. The location is not meant to be user serviceable.

I'm trying to come up with a way in the future were the saved images do not appear in Asset management at all. I don't currently know a way around these limitations with Craft.

But once again, the saved images Ansel generates are ephemeral in that any edits to the image in the field will generate new images. And these images are not meant to be seen by users or managed. This is documented: https://buzzingpixel.com/software/ansel-craft/documentation/field-type-settings#uploadSaveDirectories