Can this allocation be avoided?
Either by stack-alloc or renting the array from the array-buffer.

reverted by 40b7be8 because a build failure https://github.com/SixLabors/ImageSharp/actions/runs/12982387631/job/36202132583,
I haven't found a beautiful solution yet

this.subIfds.lenght is almost always a small number: 1,2, <5

You can stackalloc an ulong[128] working buffer outside the loop, then in the loop slice it down if sz <= 128 or allocate an array otherwise.

@antonfirsov I forgot to mention that the loop body is executed almost always 1 time,
or frequently it is not even executed at all (subIfds==null),
the task file is the only file where there are 4 loop iterations.

almost always 1 time

Is there any practical limit on the maximum number of subIfd-s? CA2014: Potential stack overflow. is a valid static analyzer finding if a malicious actor can construct a file with a high number of subIfd-s. We need to prepare the code for such edge-cases while optimizing it for the sane ones.

L195 clears the list (so count = 0). Is this condition necessary then?

L198 can add to subIfds,
nested sub ifd(s)