morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #8162] [Design] Raw raster rendering to PNG through CLI and MCP #4692

New issue

Open

opened 2026-10-31 00:52:31 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-31 00:52:31 +00:00

Owner

Originally created by @zlocorp on GitHub (Oct 30, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8162

I’d like to discuss adding generic raw raster inspection to REA through CLI and MCP.

Firmware and other binary files can contain images without a standard image header. When their layout is known, a preview would make it easier to inspect the data without writing a separate decoder for each project.

The caller would provide an explicit source byte range and pixel layout. The tool would produce a PNG preview and a manifest recording that range, its hash, and the decoding parameters. The source file would remain unchanged.

Proposed scope

1-bit monochrome; 1/2/4/8/16-bit grayscale; indexed 1/2/4/8-bit pixels with an explicit palette.
Common packed RGB/BGR and alpha formats through named presets, plus an explicit channel descriptor for less common layouts.
Width, height, row stride, row direction, byte order and packed-pixel bit order supplied explicitly where applicable.
Explicit palette transparency, color key and straight/premultiplied alpha handling.
Shared decoding logic for CLI and MCP, with bounded input/output sizes and image dimensions.
Synthetic fixtures covering pixel values, layout options, malformed or truncated input, and resource limits.

The initial preview would use RGBA8. Higher-depth input such as gray16 would therefore lose precision during conversion; the manifest should make that conversion explicit. PNG would be the initial export format, separate from the decoding core.

Automatic format detection, decompression, container-specific parsing, GPU texture formats and tiled/swizzled layouts would be outside this proposal.

Bitmap fonts

A separate follow-up would reuse the decoder for bitmap glyphs and atlas previews, with explicit glyph offsets, variable dimensions, metrics and optional character mapping. Font-container parsing would remain outside the generic renderer.

Questions before implementation

Would a built-in provider be an appropriate integration point for this capability?
Which format subset would you prefer in the first PR?
How should the selected byte range and its hash fit the existing artifact/subject identity model?

I’m opening this discussion before substantial provider integration so the scope and architecture can be agreed first.

Originally created by @zlocorp on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8162 I’d like to discuss adding generic raw raster inspection to REA through CLI and MCP. Firmware and other binary files can contain images without a standard image header. When their layout is known, a preview would make it easier to inspect the data without writing a separate decoder for each project. The caller would provide an explicit source byte range and pixel layout. The tool would produce a PNG preview and a manifest recording that range, its hash, and the decoding parameters. The source file would remain unchanged. ## Proposed scope - 1-bit monochrome; 1/2/4/8/16-bit grayscale; indexed 1/2/4/8-bit pixels with an explicit palette. - Common packed RGB/BGR and alpha formats through named presets, plus an explicit channel descriptor for less common layouts. - Width, height, row stride, row direction, byte order and packed-pixel bit order supplied explicitly where applicable. - Explicit palette transparency, color key and straight/premultiplied alpha handling. - Shared decoding logic for CLI and MCP, with bounded input/output sizes and image dimensions. - Synthetic fixtures covering pixel values, layout options, malformed or truncated input, and resource limits. The initial preview would use RGBA8. Higher-depth input such as gray16 would therefore lose precision during conversion; the manifest should make that conversion explicit. PNG would be the initial export format, separate from the decoding core. Automatic format detection, decompression, container-specific parsing, GPU texture formats and tiled/swizzled layouts would be outside this proposal. ## Bitmap fonts A separate follow-up would reuse the decoder for bitmap glyphs and atlas previews, with explicit glyph offsets, variable dimensions, metrics and optional character mapping. Font-container parsing would remain outside the generic renderer. ## Questions before implementation 1. Would a built-in provider be an appropriate integration point for this capability? 2. Which format subset would you prefer in the first PR? 3. How should the selected byte range and its hash fit the existing artifact/subject identity model? I’m opening this discussion before substantial provider integration so the scope and architecture can be agreed first.

bsakaguchi referenced this issue

2026-10-31 01:13:50 +00:00

[PR #4692] [CLOSED] fix(apple): retain unread inventory files as unavailable components #6360

bsakaguchi commented

2026-11-01 21:11:14 +00:00

Author

Owner

@BhargavGembali commented on GitHub (Oct 31, 2026):

I'd be interested in contributing an implementation for this.

My initial approach would be to start with a shared raw raster decoding core, independent of CLI/MCP, and then integrate it through the existing REA architecture.

I'd suggest keeping the first PR focused on 8-bit grayscale, RGB888/BGR888 and RGBA8888/BGRA8888, including source-range validation, stride handling, PNG generation and a reproducible manifest.

Before starting substantial implementation, I'd like to understand the existing artifact/subject identity model and provider composition conventions to ensure the feature fits the current architecture rather than introducing duplicate infrastructure.

Would this scope be suitable for an initial contribution? I'd be happy to investigate the existing implementation patterns and prepare a focused PR.

@BhargavGembali commented on GitHub (Oct 31, 2026): I'd be interested in contributing an implementation for this. My initial approach would be to start with a shared raw raster decoding core, independent of CLI/MCP, and then integrate it through the existing REA architecture. I'd suggest keeping the first PR focused on 8-bit grayscale, RGB888/BGR888 and RGBA8888/BGRA8888, including source-range validation, stride handling, PNG generation and a reproducible manifest. Before starting substantial implementation, I'd like to understand the existing artifact/subject identity model and provider composition conventions to ensure the feature fits the current architecture rather than introducing duplicate infrastructure. Would this scope be suitable for an initial contribution? I'd be happy to investigate the existing implementation patterns and prepare a focused PR.

bsakaguchi commented

2026-11-01 21:11:14 +00:00

Author

Owner

@zlocorp commented on GitHub (Oct 31, 2026):

@BhargavGembali Thanks for offering to help! I have an existing workflow that requires working with raw graphics. I’ve implemented similar functionality in my own tooling and encountered limitations, which is why I’d like to contribute a general-purpose solution to REA. I already have a preliminary implementation plan

I’m planning to work on the shared decoding core and support for the formats needed by my workflow. If you’re interested in contributing, you could then add formats or other capabilities you need on top of that same core. That would help us avoid duplicating work and keep the implementation shared and extensible.

I’d first like to agree on the architecture and scope of the initial PR with the maintainer. Are there specific formats or use cases you’d like to add?

@zlocorp commented on GitHub (Oct 31, 2026): @BhargavGembali Thanks for offering to help! I have an existing workflow that requires working with raw graphics. I’ve implemented similar functionality in my own tooling and encountered limitations, which is why I’d like to contribute a general-purpose solution to REA. I already have a preliminary implementation plan I’m planning to work on the shared decoding core and support for the formats needed by my workflow. If you’re interested in contributing, you could then add formats or other capabilities you need on top of that same core. That would help us avoid duplicating work and keep the implementation shared and extensible. I’d first like to agree on the architecture and scope of the initial PR with the maintainer. Are there specific formats or use cases you’d like to add?

bsakaguchi commented

2026-11-01 21:11:14 +00:00

Author

Owner

@BhargavGembali commented on GitHub (Oct 31, 2026):

@zlocorp That sounds like a good approach! I agree that having a shared decoding core is the right way forward. It would make the implementation more maintainable and allow additional formats and capabilities to be introduced without duplicating the underlying logic.

For my part, I'd be particularly interested in supporting common packed pixel formats such as RGB565, 1/2/4-bit grayscale, indexed color with palettes, and different channel/byte ordering configurations. These are useful when working with firmware graphics and embedded display buffers.

I'd also like to see the core remain independent of PNG encoding, with a canonical RGBA output that different interfaces or exporters can consume.

I'm happy to align with your preliminary implementation plan and work around the architecture you propose. I agree that getting the initial scope and design approved by the maintainer should come first.

Looking forward to collaborating on this!

@BhargavGembali commented on GitHub (Oct 31, 2026): @zlocorp That sounds like a good approach! I agree that having a shared decoding core is the right way forward. It would make the implementation more maintainable and allow additional formats and capabilities to be introduced without duplicating the underlying logic. For my part, I'd be particularly interested in supporting common packed pixel formats such as RGB565, 1/2/4-bit grayscale, indexed color with palettes, and different channel/byte ordering configurations. These are useful when working with firmware graphics and embedded display buffers. I'd also like to see the core remain independent of PNG encoding, with a canonical RGBA output that different interfaces or exporters can consume. I'm happy to align with your preliminary implementation plan and work around the architecture you propose. I agree that getting the initial scope and design approved by the maintainer should come first. Looking forward to collaborating on this!

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#4692

No description provided.

Rows
Columns