fix(fits): read/write color FITS image using the correct convention - #5385
Open
lgritz wants to merge 1 commit into
Open
fix(fits): read/write color FITS image using the correct convention#5385lgritz wants to merge 1 commit into
lgritz wants to merge 1 commit into
Conversation
FITS has no formal notion of color channels, just numbered axes, and OIIO's guess for a 3D color image (NAXIS1 = nchannels, interleaved) was wrong: research while investigating issue AcademySoftwareFoundation#5384 turned up no real-world FITS software using that layout. The universal convention is NAXIS3 = nchannels, one full-resolution plane per channel, the same layout astronomical software uses for spectral and Stokes cubes. Reader and writer now both use only that convention. The old NAXIS1-interleaved guess is dropped entirely rather than kept for compatibility: nothing but OIIO itself ever produced or consumed it, and it silently misread genuine external color cubes as volumes, which was the actual bug in AcademySoftwareFoundation#5384. Such old files now read as a plain grayscale volume instead. We feel comfortable with that choice because (a) no software but OIIO wrote the other convention, (b) no other software could have properly read or displayed the incorrect files OIIO was writing, yet nobody ever pointed out the error or complained in any way until AcademySoftwareFoundation#5384. I am interpreting that as very strong circumstantial evidence that there are none of these wrong image OIIO produced that people still need to read with the wrong conventions. Also fix stale, meaningless channel names, and add real names where the header supports it (STOKES axis codes, or informal FILTERn/BANDn keywords). If there are multiple channels and none of these conventions are apparent, default to just calling it R, G, B. Document the convention and channel-naming rules in builtinplugins.rst. For the rarer NAXIS=4 (volume+color) case, apply the same pattern: the channel axis is NAXIS4, the slowest-varying one, not NAXIS1. There's no known real-world convention to confirm this against like there was for NAXIS=3, but it's the natural extension of the same reasoning. Fixes AcademySoftwareFoundation#5384 Assisted-by: Claude Code / Sonnet 5 Signed-off-by: Larry Gritz <lg@larrygritz.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FITS has no formal notion of color channels, just numbered axes, and OIIO's guess for a 3D color image (NAXIS1 = nchannels, interleaved) was wrong: research while investigating issue #5384 turned up no real-world FITS software using that layout. The universal convention is NAXIS3 = nchannels, one full-resolution plane per channel, the same layout astronomical software uses for spectral and Stokes cubes.
Reader and writer now both use only that convention. The old NAXIS1-interleaved guess is dropped entirely rather than kept for compatibility: nothing but OIIO itself ever produced or consumed it, and it silently misread genuine external color cubes as volumes, which was the actual bug in #5384. Such old files now read as a plain grayscale volume instead.
We feel comfortable with that choice because (a) no software but OIIO wrote the other convention, (b) no other software could have properly read or displayed the incorrect files OIIO was writing, yet nobody ever pointed out the error or complained in any way until #5384. I am interpreting that as very strong circumstantial evidence that there are none of these wrong image OIIO produced that people still need to read with the wrong conventions.
Also fix stale, meaningless channel names, and add real names where the header supports it (STOKES axis codes, or informal FILTERn/BANDn keywords). If there are multiple channels and none of these conventions are apparent, default to just calling it R, G, B. Document the convention and channel-naming rules in builtinplugins.rst.
For the rarer NAXIS=4 (volume+color) case, apply the same pattern: the channel axis is NAXIS4, the slowest-varying one, not NAXIS1. There's no known real-world convention to confirm this against like there was for NAXIS=3, but it's the natural extension of the same reasoning.
Fixes #5384
Assisted-by: Claude Code / Sonnet 5