File-oriented operations rarely "read the whole image into memory", however:
- It will always need to read the full header (which varies in size by format)
- It will always need to allocate a row buffer (or tile buffer, if the format is tile-oriented) for input and another for output (in the case of conversion).
- If a compression algorithm is used, additional memory will be needed to hold the decompressed copy
- The application has no control over the operating system, which may cache everything it's asked to read until some threshold is reached.
- Likewise, most disks have a RAM cache, and the OS has no control over what the disk retains.
Generally speaking, no competently-developed application (a class of which GDAL is certainly a member) will ever do more I/O than is necessary. Such applications will also strive to minimize memory use, but if the choice is between using an extra 64Kb of RAM or re-reading a file block (and especially re-reading a file block repeatedly), then using memory is going to win out. Back in the day of systems with 8-32Mb RAM, this was a cruel choice, but with 8Gb-256Gb RAM, a 64K block is a drop in the bucket.
In your particular case, the I/O required to read a 25x25 pixel window depends on:
- The pixel depth of the image (unknown)
- The pixel width of the image (unknown)
- The number of bands (3)
- The pixel interleave of the output image (assumed none)
- The tile blocking of the image (unknown)
- Any pyramiding that may be embedded in the format (assumed none)
- Any compression done per tile (assumed none)
If we assume that it is 8-bit depth, a square image, and no tile blocking, then then we have a 13219x13219 image with a 62117 byte header. The application would need to read the header, plus 25 rows times three bands. The input I/O would be 101774 bytes, but the RAM used would only be 75336 (header plus the row buffer). On output, assuming a 1024 byte header, only 2899 bytes would be written, requiring only the header (1024) and the row buffer (25) in RAM.
If the same image was instead 13056 (W) x 13384 (H), with a 256x256 tiling scheme (and no compression), at most 4 tiles would need to be read. If we assume best case, then the I/O is 260096 bytes (63488 header plus 256x256 tile buffer, three times), and the memory is 129024 bytes (header plus one tile). But if you were unlucky, and the 25x25 pixel chunk you wanted crossed four tiles, then you'd need 849920 bytes of input I/O, and 194560 bytes of RAM (because a second tile would need to be cached to fill the output buffer, vice reading an extra tile 24 times for each band).
So, we see that the details of how much I/O and RAM is required for any specific file is critically linked to the actual file organization and the intended use (neither of which may be optimal with respect to the other), but it's usually safe to assume that GDAL will use the minimum necessary for the task (unless otherwise influenced by unwise parameters).