feat(sgi): Implement RLE encoding support for output

[jessey-git]

Description

Implement RLE compression support for the SGI output plugin. Reading RLE encoded images was already supported, but writing was never done up until this point.

Tests

The existing sgi test seems sufficient to catch issues and it covers input/output of both 1 byte-per-pixel and 2 byte-per-pixel files.

Notes

The documentation for the image plugins are sometimes not very clear about which attributes are relevant for input vs. output. There's usually 3 sections: Attributes, Attributes for Input, and Attributes for Output.

Before this PR, SGI mentioned the "compression" attribute in the "general" Attributes section (rather than say just the Input section), which caused a bit of grief as the only way to discover that RLE was not implemented for Output was to glance at the file size of the resulting file... I had assumed that compression was supported for output too but discovered that it was not.

Now that this PR implements the attribute for output I've left the documentation as-is in the "general" Attributes section since it applies to both read/writing now. But I'm open for suggestions here.

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested somewhere in the
  testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[lgritz]

LGTM (pending CI completing)!

[lgritz]

As usual, you're a hero for filling in these little gaps.

But I have to wonder, is there somebody out there needing or asking for this?

I always assumed that sgi was truly a legacy format (I mean, the "SGI" name says it all, right?) where having a reader might help somebody who had an old image from back in the day that they want to read and convert to something modern, but that probably nobody would want to write any new files in that format. I'm not even sure I would have guessed that a writer was necessary at all.

Is somebody out there still lovingly writing sgi image files?

[jessey-git]

I thought about trying to put together some words on the initial PR to alleviate the absurdity of this situation but I couldn't form something eloquent enough to both pay homage too, and laugh at, the legacy here, mere hours from 2026 :)

While I smile at the prospect of someone out there still lovingly writing these files, it is very much most likely just a passing thought.

The PR was born simply out of an engineering desire to "have no regressions" once I get to removing old SGI format IO code in Blender. We moved to OIIO for most formats some years ago but a few remained due to one reason or another. SGI's reason was that it was indeed legacy and perhaps ready for removal. But then I felt sorry for it and finally decided to look into it. I was nearly ready to checkin too before I noticed the file sizes lol.

[lgritz]

Totally understandable answer!

Software development can back us into corners in which every individual step is the most reasonable thing to do at that point, even if the route as a whole looks totally absurd to anybody who didn't come along for the trip.