Optimize code (scoring methods)

[davidfischer-ch]

By using numpy or other nice libary.

[derVedro]

@davidfischer-ch
I think I can slowly start working on it with a couple of PRs. I plan to make some structural changes and maybe break API in later PRs. However, the first few will do without them. Let's see where the journey takes us.

[derVedro]

This first one #47 is a low-hanging fruit and should reduce execution time by approximately 10%.

[derVedro]

The second one #48 is a low-hanging fruit too. Done some math and tried another way to iterate over the pictures in score()

[derVedro]

This third one #49 is pretty big and brings a nice performance boost! The magic comes from using numpy's vectorization, precomputing the score, and caching the importance values.

The results are slightly different from the original version, but I'm confident they're correct. In fact, I found a bit of a quirk in the old code: the importance was being calculated at a larger size than necessary. Think of it like having an image that's too big, and when you sample values from it (without any interpolation, like Image.Resampling.NEAREST), you get different pixels than if you had used a correctly sized image from the start. My fix computes importance at the exact size it's needed, which clears that up. Because of this correction, we should update the tests to expect the new (accurate) results.

Looking ahead, I have a couple of ideas for further tweaks (haven't tried them yet, just thinking out loud):

• Switching to float32 could speed things up even more with vectorization. I suspect the precision loss would be negligible, if any.

• We could simplify the result dictionary by dropping the separate skin, detail, saturation results and doing some precomputation earlier. It would change the API a bit, but honestly, who's really using the individual feature scores? The total is what most people care about.

[derVedro]

So, #51 a low-hanging fruit. Summing the skin, detail and saturation as early as possible would save some compute time, that scales with the crop size - the larger the input crop size, the more we save.

Possible downside, the separate skin/detail/saturation scores are now not in the resulting crop. That change the API. That NEEDS to be communicated to the end users of the library in changelog.