This option is already present in admin: options-image.
What I'm asking for is to have this option working also for the images that don't need to be resized for the regular view.
I found a way for have those cached, but it required a change in i.php, line 201 current nightly.
From:
if (!cacheImage_protected($newfilename, $imgfile, $args, $allowWatermark, [b]false[/b], $theme, $album))
To:
if (!cacheImage_protected($newfilename, $imgfile, $args, $allowWatermark, [b]true[/b] , $theme, $album))
So the option is already there but I don't understand how to add it in theme's options.

There is already an option for that on Options > Image > Full image protection.

Yes, I saw it. Maybe it wasn't clear but I tryed to explain that the existing option only works for "strict" full image cache, not if you want to cache sized images that don't need to be resized because they are already small enaugh.

If an full image does not need to be resized because of this it is used directly. Therefore use the full image cache option. (unless there is a bug)

It is used directly, anyway if the image is not in cache then the request is processed through i.php every time.
For me it would be nice to avoid this passage when it's not needed.
I'm able to obtain this behavior but I would like to avoid changes in the main code.

Uncached images are always processed by i.php to be actually cached. If you think it is a bug and the full image is never cached although you set the option please open a ticket with the exact description. Thanks.

You are true acrylian, I didn't notice it before because i have full image disabled in my theme, but actually that option doesn't work for full images either. They are never cached, not only if they don't need to be resized for standard image view!
I'll open a ticket. Is it possible to recover my old password or to delete my old account from track so that I can register again with my nickname?

Regarding the password recover, I am not sure right now. But if "bic" is your trac account name as well I could delete it.

Yes, it was bic.
Meanwhile I went further into this and I discovered that the 2 situations we where discussing above are actually different.

Case 1) Full images are smaller than sized images.
It's easy to force cache for them, reflecting the option in Image>Full_image. Just one line added and one line edited in i.php.

Case 2) Full images are bigger than sized images.
The force cache option doesn't work and I didn't find a simple workaround.

Account on trac is removed. You can now re-register. My collegue who is the expert on the image processing stuff will surely soon respond as well.

Perhaps I do not understand the issue. The image is "cached" in its original location. The purpose of caching is to prevent unnecssary image processing. When the image is the correct size it need not be reprocessed.

It seems useless but imho that option is there for a good reason. I've made many tests and the performance when the image is forced in cache is much better after the first request, even if no processing is needed for the image.
Btw, at least for Case 1, that is where it's more usefull, is really easy to get it working:

File: zp-core/i.php

before line 201 added the line:
$force_cache=getOption('cache_full_image');

ex line 201, now 202, changed to:
if (!cacheImage_protected($newfilename, $imgfile, $args, $allowWatermark, $force_cache, $theme, $album)) {

Well, the particular option you have used has nothing to do with i.php and everything to do with full-image.php. It is there to allow to cache or not the image if it has been watermarked. That is optional for quite good reasons--storage space vs. processing time trade-offs. Most visitors do not elect to view the full sized image, so the trade-off is reasonable.

Hijacking this option for your us is a pretty bad idea.

On the other hand, I agree that the performance, especially over time, favors just caching the image. There is really quite a bit of computation made to see if the caching can be bypassed. It would be unreasonable to place that test where the image URLs are generated since that would be a mulitplicative effect. Also, most images will be cached, so the test for a small percentage of cases just does not computer[sic].

With tonight's build all normal images will be cached.

Ok, now everything is clear. At the beginning of this topic my idea was that the force cache option was there only for real full images but I didn't get the connection with watermark.
On my production site I already cache all (sized or not) images for image.php page but I'm sure you'll find a better way to do it.
There will be many benefits, also for easier image preload in browser.