I've upgraded again my online site, from 1.5.1 to 1.53.b, and changed the filigrane.png (I've made a 600x320 picture)
Online site is OK. No more cache problem.

Appreciate the backend option that allow you to select all, unpublished or published pictures.
For sure, I will find other useful new possibilities.

Okay, thanks. Perhaps having just a minimum size requirement for watermark images is a pragmatic fix. Afterall you can define how large it should become in relation on the image later.

It seems there is no general minimum size recommendation possible. If it works correctly depends on the watermark size and the resized size of the image depending on the percentage value and if upscaling is allowed. So it is a bit relative because of that.

So recommendation would be if it does not work, try a larger watermark right now…

@ctdlg Please try the support build again. The issue occured because of upscaling of watermarks or if the watermark was not resized at all. Since upscaling basically never looks good anyway, we also have removed that option now. So watermarks from now on never will be larger than their original size.

I have not tried the new support buid yet, I will do it soon.

Remark

I cleaned my image cache and rebuilt it.
Many images end with a number, and I got no error rebuilding the cache. This was not supposed to work. ( now using 1.5.3b)
I had no problem with 1.5.1 too.
Example : "I-Img_6236.jpg" -> image caching gives me no problem.

The only "error" is :
only the 64 first albums are automatically scanned and computed.

I had to enter all other albums admin pages manually to regenerate those caches.

64 is 2 power 6.
Strange behavior !

Check what mode of the cacheManger you are using. There are two now: The classic one and the newer cURL based one. The latter works better if it works as it somehow does not behave the same on all servers. Works fine locally and on our own but not on the server of my colleague.

If you iuse the classic mode this is not reliably create all cached images and never did, you may have to run it several times. Thus the new way was introduced.

Anyway, precaching is not necessary as ZP will do whenever needed.

The support build has not changes in this area but please test for the actual issue regarding watermarks discussed here. We need the feedback for releasing 1.5.3.

I've tried your new build, and I can confirm the actual issue regarding watermarks is solved.

cURL does work on my server, 85 albums out of 120 were re-generated.

Thanks for the feedback!

> cURL does work on my server, 85 albums out of 120 were re-generated.

Yes, but somehow the precaching does not work as expected on all servers. It works generally as intended if you see a frequently growing list of images/albums being processed. If you instead see a blank page for quite some time and all appears at once it does not. We haven't found out why this behaves so different on some servers. Therefore there is an option to use the old way as it was before, even if that is not that reliable either.