HDR file format: replace FreeImage HDR loader with our own from-scratch implementation #743
Conversation
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
Relates to #739 . Thank you to @warrengalyen for catching and reporting. FreeImage's HDR support is problematic. What a surprise! (/s, I've spent years replacing FreeImage code with my own over and over again because of poor implementation quality.) Specifically, FreeImage imposes unnecessary restraints on property lines in HDR headers. If a header line exceeds 256 chars - something that can and does happen in real-world images - FreeImage's parser just throws up its hands and quits. Similarly, FreeImage doesn't handle incoming exposure data (which prevents correct color-mapping) or color-correction data, it rejects RLE packets with 0-length (which again, occur in real-world images), and it's slow because it relies on frexp() on every pixel conversion. It also uses a number of non-standard color-conversions at both import and export time (like normalizing against the largest channel value on each pixel, which... why???). When saving HDR images, it also writes non-standard 0-value exposure tags which causes HDR images to fail to load in e.g. GIMP. Needless to say, since FreeImage is no longer being actively developed, the easiest option was for me to (yet again) just write an HDR parser from scratch. The HDR spec is straightforward, relatively short, and freely available: https://radsite.lbl.gov/radiance/refer/filefmts.pdf ...so this wasn't actually too bad. This commit just enables basic compatibility of common HDR image formats. Still TODO is... - Handling embedded exposure and color-correction data at import-time - XYZE color space (can't find test images so I'll need to make my own, argh) - Saving HDR images (still uses FreeImage as of this commit) Performance is already nicely improved over the old implementation, and previously unsupported images are now loaded just fine. Additional HDR features landing soon, I hope!
...including: - XYZE color format! (Still can't find real-world test files here, but if I manually edit HDR files and change their format to XYZE, then load the image to both PD and Photoshop, the results are identical. Good enough for me!) - Exposure - Color primaries As with most older formats, these changes also required a lot of additional error-handling to account for malformed files. The loader should be pretty robust now!
...as downloaded from the Lawrence Berkley National Laboratory archive here: https://radsite.lbl.gov/radiance/pub/pics/index.html These very old files lack the expected magic ID at the start of the file, but if we see the .pic extension, we'll ignore that problem and look for a valid FORMAT tag in the first 1024 chars of the file, If found, we'll attempt to load anyway. This allows all the files in that archive to load without trouble!
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.
Fixes #739. Thank you to @warrengalyen for catching and reporting.
PhotoDemon has historically used the 3rd-party FreeImage library to load HDR images. FreeImage has not been updated in 8 years but its problems run even deeper than that. For HDR images specifically, it has a lot of weird quirks that just don't make sense - it enforces line-length requirements on header lines which break valid files (see #739), it uses a non-standard exposure calculation when converting from float to RGB, it ignores embedded color correction values and provides no way for the caller to even see those values, it writes bad exposure values which prevents loading saved HDR images in GIMP and other software, it doesn't cover format variations like the XYZ color space, and its performance is mediocre at best.
This commit fixes all those problems with a new, from-scratch HDR loader built specifically for PhotoDemon.
HDR format support is now faster, much more comprehensive, and color accuracy of imported images is greatly improved. All format variations are supported and very-old Radiance files are now supported for the first time.
This merge only overhauls HDR import; HDR export support is still TODO.