read_image_file eagerly decodes and re-encodes the whole image, costing ~36s and ~7.4 GB on a large GeoTIFF

This was generated by AI during triage.

Spun off from #2417 (which fixes the misleading error message for this case) and #2388.

read_image_file() in labelme/_label_file.py decodes the full image with PIL and re-encodes it to PNG/JPEG in memory before labelme/_app.py ever calls QtGui.QImage.fromData(). For the 3.4 GB GeoTIFF reported in #2388 (37296 x 49319, 4 bands, LZW) this cost ~36.3s and ~7.4 GB peak RSS, and produced a 7.3 MB PNG that Qt then rejected anyway.

So on the too-large path the user waits minutes and the process peaks at multiple GB purely to produce bytes that are immediately discarded. #2417 makes the resulting dialog accurate but does not make it fast, and deliberately so: the message fix stands on its own and should not be held up by this.

A cheap improvement would be to read the header dimensions first (PIL opens lazily; Image.open(...).size does not decode pixels) and bail out before the decode when the image cannot possibly be displayed. That would turn a multi-minute wait plus a 7.4 GB spike into a near-instant error.

Tiled or pyramid rendering so that such images can actually be opened is a separate, larger feature request and is not what this issue asks for.