Cs3d/truncated stream graceful decode#4
Open
wayfarer3130 wants to merge 412 commits intosync/aous-master-2026-04-28from
Open
Cs3d/truncated stream graceful decode#4wayfarer3130 wants to merge 412 commits intosync/aous-master-2026-04-28from
wayfarer3130 wants to merge 412 commits intosync/aous-master-2026-04-28from
Conversation
…he data is around 16bits/sample of more, coded losslessly.
…. Also addresses CodeQL.
…ify -bit_depth for .pfm files -- this temporary.
Adding support for NLT marker segment of type 3. The code is not very complete, but it is in a useful state for publishing. The code also fixes an important bug in the block decoder in commit aous72@9f8011c This PR adds partial support for .pfm files, as explained next. Lossy compression is not supported -- it is possible to add support at some future point. Reversible coding of .pfm files is supported, where the NLT marker is automatically inserted. However, the current implementation supports only 28-bit for encoding 27-bit for decoding. Therefore floating point values stored in a .pfm file, which are 32-bit, need to be truncated. Using the '-bit_depth' option, ojph_compress can perform this truncation. 'ojph_compress' should work correctly with codestreams generated with ojph_compress, converting truncated values back to normal floating point values.
There are three changes here. The first is the most important. Change 1: Thank you @cary-ilm * Rename src/core/common to src/core/openjph OpenJPH headers are included in application code via `#include <openjph/ojph_version.h>`. The headers are expected to be in a folder named "openjph". The cmake configuration places them there in the installation step. However, if OpenJPH is incorporated into an application via cmake's `add_subdirectory`, there is no installation step, so there is no "openjph" folder, leading the `#include <openjph/ojph_version.h>` to fail. Renaming the "common" directory to "openjph" resolves the build issue, since the headers then live inside the source tree in a directory with same name as the installation. The use of the "common" directory name is entirely internal to the OpenJPH build, it has no impact on the installation. The name should be arbitrary, so there should be no downside to renaming it this way. Signed-off-by: Cary Phillips <cary@ilm.com> * This fixes PR compilation --------- Signed-off-by: Cary Phillips <cary@ilm.com> Co-authored-by: Cary Phillips <cary@ilm.com> Change 2: Message type constants are not descriptive enough, and they maybe inadvertently replaced by a preprocessor macro. They are: ``` enum OJPH_MSG_LEVEL : int { ALL_MSG = 0, // uninitialized or print all message INFO = 1, // info message WARN = 2, // warning message ERROR = 3, // error message (the highest severity) NO_MSG = 4, // no message (higher severity for message printing only) }; ``` They were replaced with ``` enum OJPH_MSG_LEVEL : int { OJPH_MSG_ALL_MSG = 0, // uninitialized or print all message OJPH_MSG_INFO = 1, // info message OJPH_MSG_WARN = 2, // warning message OJPH_MSG_ERROR = 3, // error message (the highest severity) OJPH_MSG_NO_MSG = 4, // no message (higher severity for message printing only) }; ``` which is less like to have the identified issues. Change 3: Addresses the problem identified in @clshortfuse in issue aous72#235
Adds ARM CPU feature detection for FreeBSD and OpenBSD
* A bug fix -- detect illegal codestream parameters. * Version bump.
This fixes a bug when the number of tiles is 0, and, in resilient mode, when the the start of tile-part segment (SOT) has an incorrect index, Isot.
* This fixes a bug introduced in 0.26.1
* Add initial support for libfuzzer --------- Co-authored-by: Aous Naman <aous@unsw.edu.au>
Fixes issues with OSS-Fuzz.
…72#252) * Renamed file to avoid duplicate library names in custom builds. * Rename file reference from ojph_mem.c to ojph_mem_c.c Updated the license to refer to the new name. --------- Co-authored-by: Aous Naman <aous@unsw.edu.au>
… a codestream (aous72#253) Validate SIZ marker segment content after reading it from a codestream.
…erator, deletes copy constructor and assignment operator (aous72#242) This adds move constructor and assignment operator, deletes copy constructor and assignment operator.
Improves fuzzing build
Correcting a move bug that was introduced earlier.
…s72#243) This caused wrong encoding in the OpenEXR integration, which then resulted in "Error decoding a codeblock" while decoding. Use std::call_once to avoid this. Signed-off-by: Brecht Van Lommel <brecht@blender.org>
…s::buf (aous72#262) * Fix 32-bit ARM SIGBUS: align elastic allocator payload for coded_lists::buf Problem: OpenJPH’s mem_elastic_allocator lays out memory as: [ stores_list header ][ payload... ] Payload holds placement-new `coded_lists` instances via get_buffer(): p = new (cur_store->data) coded_lists(needed_bytes); Each `coded_lists` sets its bitstream pointer as: buf = (ui8*)this + sizeof(coded_lists) So the address of `buf` is: slab + offset(stores_list → data) + sizeof(coded_lists) Previously, `data` was set to immediately after the `stores_list` object (i.e. offset sizeof(stores_list) from the slab start). The compiler-chosen size of `stores_list` is not guaranteed to be a multiple of 8 or 16. For some layouts, the first `coded_lists` header therefore landed at an offset such that `buf` ended up at an address congruent to 4 (mod 8): 4-byte aligned but not 8-byte aligned. On strict 32-bit ARM, libc memcpy used when copying or flushing these bitstreams (e.g. wide loads such as LDRD) can require 8-byte alignment. Misaligned `buf` then triggers SIGBUS. This showed up in practice when OpenJPH was used from OpenEXR (Huffman-table / compressed data flush paths) on armv6 and armv7 machines. Root cause: The failure is not in `coded_lists` itself but in where the payload region begins relative to the slab. Padding only inside `coded_lists` or rounding the *user* allocation size is insufficient if the *first* byte of the payload region is still at a bad offset from the malloc base. Solution -------- 1. stores_list: Introduce offset16() = round_up(sizeof(stores_list), 16). Construct with: data = orig_data = (ui8*)this + offset16() so the first byte available for `coded_lists` is 16-byte aligned from the start of the slab. eval_store_bytes() adds this offset so malloc allocates enough space for header + padding + payload. 2. get_buffer: Round (needed_bytes + sizeof(coded_lists)) up to a multiple of 16 so successive `coded_lists` regions in the same store keep consistent alignment as `data` advances. Together, `coded_lists` headers and their `buf` pointers stay suitably aligned for memcpy/fwrite on 32-bit ARM while preserving existing allocator behavior on other platforms. Analysis and solution made with the help of Cursor / Claude Opus 4.5 Signed-off-by: Cary Phillips <cary@ilm.com> * Changed offset16() to stores_list_size16() in ojph_mem.h Changed function name from offset16() to the more descriptive name stores_list_size16(). --------- Signed-off-by: Cary Phillips <cary@ilm.com> Co-authored-by: Aous Naman <aous@unsw.edu.au>
* Add Linux-ARM32 Build * Make build_arm32 a manual CI job Added workflow_dispatch input options for manual job selection and log level configuration. Make build_arm32 build an optional build --------- Authored by Pierre Lemieux <pal@sandflow.com> Co-authored-by: Aous Naman <aous@unsw.edu.au>
* Extend fuzzing harness to add more reachability Goal is to expand code coverage * Add encoder fuzzer Signed-off-by: David Korczynski <david@adalogics.com> --------- Signed-off-by: David Korczynski <david@adalogics.com>
… Windows (aous72#265) * Normalize line endings to LF * Fix ARM64EC builds by excluding ARM64EC from x64(_M_X64) detection on Windows
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
15 participants
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.
No description provided.