Is gloss source logic removal - metadata handling update

This commit is contained in:
2025-05-06 22:59:08 +02:00
parent 932b39fd01
commit d394efe13d
6 changed files with 18 additions and 81 deletions

View File

@@ -34,10 +34,10 @@ The pipeline steps are:
* Iterates through files classified as maps in the `SourceRule`.
* Loads images (`cv2.imread`).
* **Glossiness-to-Roughness Inversion**:
* The system identifies a map as a gloss map if its input filename contains "MAP_GLOSS" (case-insensitive).
* If such a map is intended to become a roughness map (e.g., its `item_type` or `item_type_override` in the `SourceRule` effectively designates it as roughness), its colors are inverted.
* The system identifies a map as a gloss map if its input filename contains "MAP_GLOSS" (case-insensitive) and is intended to become a roughness map (e.g., its `item_type` or `item_type_override` in the `SourceRule` effectively designates it as roughness).
* If these conditions are met, its colors are inverted.
* After inversion, the map is treated as a "MAP_ROUGH" type for subsequent processing steps.
* This filename-driven approach is the primary mechanism for triggering gloss-to-roughness inversion, replacing reliance on older contextual flags (like `file_rule.is_gloss_source`) or general `gloss_map_identifiers` from the configuration for this specific transformation within the processing engine.
* The fact that a map was derived from a gloss source and inverted is recorded in the output `metadata.json` for that map type using the `derived_from_gloss_filename: true` flag. This replaces the previous reliance on an internal `is_gloss_source` flag within the `FileRule` structure.
* Resizes images based on `Configuration`.
* Determines output bit depth and format based on `Configuration` and `SourceRule`.
* Converts data types and saves images (`cv2.imwrite`).