---
ID: ISSUE-010
Type: Issue
Status: Resolved
Priority: High
Labels: [bug, core, image-processing, regression, resolved]
Created: 2025-04-22
Updated: 2025-04-22
Related: #ISSUE-004, asset_processor.py
---

# [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)
*   [x] Process an asset containing standard RGB maps (e.g., Color/Albedo). Verify the output map has correct RGB channel order.
*   [x] Process an asset requiring map merging (e.g., ORM from Roughness, Metallic, AO). Verify the output merged map has correct RGB(A) channel order.
*   [x] Verify image statistics in `metadata.json` remain correct (reflecting RGB values).
*   [x] Verify grayscale maps are processed and saved correctly.
*   [x] 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:**

1.  **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.
2.  **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.
3.  **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:**

```mermaid
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