[ISSUE-010]: Color Channel Swapping Regression for RGB/Merged Maps after ISSUE-004 Fix

Description

The resolution implemented for ISSUE-004 successfully corrected the BGR/RGB channel handling for image statistics calculation and potentially normal map packing. However, this fix appears to have introduced a regression where standard RGB color maps and maps generated through merging operations are now being saved with swapped Blue and Red channels (BGR order) instead of the expected RGB order.

Current Behavior

Standard RGB texture maps (e.g., Diffuse, Albedo) loaded and processed are saved with BGR channel order.
Texture maps created by merging channels (e.g., ORM, NRMRGH) are saved with BGR channel order for their color components.
Image statistics (metadata.json) are calculated correctly based on RGB data.
Grayscale maps are handled correctly.
RGBA maps are assumed to be handled correctly (needs verification).

Desired Behavior / Goals

All processed color texture maps (both original RGB and merged maps) should be saved with the standard RGB channel order.
Image statistics should continue to be calculated correctly based on RGB data.
Grayscale and RGBA maps should retain their correct handling.
The fix should not reintroduce the problems solved by ISSUE-004.

Implementation Notes (Optional)

The issue likely stems from the universal application of cv2.cvtColor(img_loaded, cv2.COLOR_BGR2RGB) in _process_maps introduced in the ISSUE-004 fix. While this ensures consistent RGB data for internal operations like statistics and merging (which now expects RGB), the final saving step (cv2.imwrite) might implicitly expect BGR data for color images, or the conversion needs to be selectively undone before saving certain map types.

Investigation needed in asset_processor.py:

Review _process_maps: Where is the BGR->RGB conversion happening? Is it applied to all 3-channel images?
Review _process_maps saving logic: How are different map types saved? Does cv2.imwrite expect RGB or BGR?
Review _merge_maps: How are channels combined? Does the saving logic here also need adjustment?
Determine if the BGR->RGB conversion should be conditional or if a final RGB->BGR conversion is needed before saving specific map types.

Acceptance Criteria (Optional)

Process an asset containing standard RGB maps (e.g., Color/Albedo). Verify the output map has correct RGB channel order.
Process an asset requiring map merging (e.g., ORM from Roughness, Metallic, AO). Verify the output merged map has correct RGB(A) channel order.
Verify image statistics in metadata.json remain correct (reflecting RGB values).
Verify grayscale maps are processed and saved correctly.
Verify normal maps are processed and saved correctly (as per ISSUE-004 fix).
(Optional) Verify RGBA maps are processed and saved correctly.

Resolution

The issue was resolved by implementing conditional RGB to BGR conversion immediately before saving images using cv2.imwrite within the _process_maps and _merge_maps methods in asset_processor.py.

The logic checks if the image is 3-channel and if the target output format is not EXR. If both conditions are true, the image data is converted from the internal RGB representation back to BGR, which is the expected channel order for cv2.imwrite when saving formats like PNG, JPG, and TIF.

This approach ensures that color maps are saved with the correct channel order in standard formats while leaving EXR files (which handle RGB correctly) and grayscale/single-channel images unaffected. It also preserves the internal RGB representation used for accurate image statistics calculation and channel merging, thus not reintroducing the issues fixed by ISSUE-004.

Implementation Plan (Generated 2025-04-22)

Goal: Correct the BGR/RGB channel order regression for saved color maps (introduced by the ISSUE-004 fix) while maintaining the correct handling for statistics, grayscale maps, and EXR files.

Core Idea: Convert the image data back from RGB to BGR just before saving with cv2.imwrite, but only for 3-channel images and formats where this conversion is necessary (e.g., PNG, JPG, TIF, but not EXR).

Plan Steps:

Modify _process_maps Saving Logic (asset_processor.py):
- Before the primary cv2.imwrite call (around line 1182) and the fallback call (around line 1206), add logic to check if the image is 3-channel and the output format is not 'exr'. If true, convert the image from RGB to BGR using cv2.cvtColor and add a debug log message.
Modify _merge_maps Saving Logic (asset_processor.py):
- Apply the same conditional RGB to BGR conversion logic before the primary cv2.imwrite call (around line 1505) and the fallback call (around line 1531), including a debug log message.
Verification Strategy:
- Test with various 3-channel color maps (Albedo, Emission, etc.) and merged maps (NRMRGH, etc.) saved as PNG/JPG/TIF.
- Verify correct RGB order in outputs.
- Verify grayscale, EXR, and statistics calculation remain correct.

Mermaid Diagram:

graph TD
    subgraph "_process_maps / _merge_maps Saving Step"
        A[Prepare Final Image Data (in RGB)] --> B{Is it 3-Channel?};
        B -- Yes --> C{Output Format != 'exr'?};
        B -- No --> E[Save Image using cv2.imwrite];
        C -- Yes --> D(Convert Image RGB -> BGR);
        C -- No --> E;
        D --> E;
    end

5.6 KiB Raw Blame History