Prepare demosaicer module to process whole image data - #22236
Prepare demosaicer module to process whole image data#22236jenshannoschwalm wants to merge 4 commits into
Conversation
There was a problem hiding this comment.
🔵 Needs a closer look
Core pixelpipe ROI behavior affects CPU and OpenCL image output and requires runtime integration validation.
Pull request overview
Prepares demosaic processing to operate on full-image input before resampling the requested output region.
Changes:
- Expands demosaic input ROI to full resolution.
- Uses full-buffer mask and RGB resampling paths.
- Keeps CPU and OpenCL behavior aligned.
File summaries
| File | Description |
|---|---|
src/iop/demosaic.c |
Requests full-image input and updates mask, CPU, and OpenCL resampling. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
There was a problem hiding this comment.
🟡 Changes recommended
Approximate previews mishandle nonzero ROI origins, and full-image demosaicing introduces substantial uncached work.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 2
- Review effort level: Balanced
7eeed3e to
50342e5
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Legacy custom orders can misplace the scaling stage, and localization inputs omit the new module.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 15/15 changed files
- Comments generated: 3
- Review effort level: Balanced
50342e5 to
34098b7
Compare
There was a problem hiding this comment.
🟡 Changes recommended
The generated introspection source is missing from the translation extraction list.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 16/16 changed files
- Comments generated: 1
- Review effort level: Balanced
34098b7 to
1390484
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Automatic-radius allocation failures are now silently persisted as a fallback radius.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 16/16 changed files
- Comments generated: 1
- Review effort level: Balanced
a114a91 to
bd5a9e6
Compare
Instead of using the given input roi we expand processed data to full piece->buff_in dimension. This is a pre-requisite for efficient caching of demosaiced output rgb data before the internal resampling. The check for the approximating demosaicers got updated for thumbs, passed parameters had to be changed as we now have to process full image data. The preview pipe uses downscaled mipmap data anyway so absolutely no need for approximation, btw the test didn't work anyway.
As the demosaicer now always process full image data we downscale to the required roi in another module enabled for all demosaiced images. Pro and against arguments for using this strategy: About cost vs. efficacy: 1. As we now always demosaic full image data the pipe is principally slower if parameters change before/inside demosaic and we use a smaller roi than full data (like when using crop). This affects all pipe types so exports will be somewhat slower especially if we crop, either by crop module or ashift. 2. Also we have to process more when zooming or dragging the roi when zoomed in. 3. As demosaic does no internal crop&scale anymore, the memory footprint is lower thus internal tilesizes can be smaller with a possible perf gain. 4. BUT: in all desktop pipes we avoid processing all modules before the demosaic downscaler after the first pipe run as we have cached data and just have to crop&scale which is much faster than re-processing from pipe start. About quality & results: All demosaicers have inferior interpolators at the border regions, depending on the demosaicer algorithm this affects the outermost 2-4 photosites. With the old method we had these minor quality pixels always on the cropped roi. As we now calculate all pixels we crop on the better data thus results will be somewhat better at the outermost areas.
1. All code required for internal crop&scale could go as we demosaic full data. 2. Simper code & parameters for the approximating interpolators. 3. The capture radius calculation could be simplified too as for having full data.
As raw opposed works on full image data code could be simplified and thus it's slightly faster.
bd5a9e6 to
1459c7e
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Thumbnail processing now creates a potentially enormous full-resolution RGBA intermediate before downscaling.
Get a fresh assessment by requesting another Copilot review.
Review details
- Files reviewed: 16/16 changed files
- Comments generated: 1
- Review effort level: Balanced
Instead of using the given input roi we expand processed data to full piece->buff_in dimension.
This is a pre-requisite for efficient caching of demosaiced output rgb data before the internal resampling.