Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Finalize ACES 2 FixedFunctions and remove warnings

Abierto
  • ¿Algo no está bien?
#2,275 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp
Área
computer-graphics

Línea de trabajo

Revisa las definiciones fixed-function de ACES y el lector y escritor YAML; después, inspecciona Config_tests.cpp en busca de "experimental" y las descripciones fixed-function en OpenColorTypes.h. Determina el orden final de los canales, la normalización y el comportamiento de descomposición; se considera terminado cuando las funciones estén finalizadas, se hayan eliminado las advertencias y se hayan limpiado los marcadores experimentales y las expectativas de prueba relacionadas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Needs Discussion

When ACES 2 was implemented, there was some uncertainty in how to decompose the overall Output Transforms into FixedFunctions, and so the YAML reader and writer issue warnings when any of these are used:

FIXED_FUNCTION_ACES_OUTPUT_TRANSFORM_20
FIXED_FUNCTION_ACES_RGB_TO_JMH_20
FIXED_FUNCTION_ACES_TONESCALE_COMPRESS_20
FIXED_FUNCTION_ACES_GAMUT_COMPRESS_20

At this point, we should try to finalize what the fixed functions are and remove the warnings.

I like having a function to convert to JMh, but there are two things I find inconvenient about the current one:

  1. The results are in the hundreds (e.g., J goes up above 800, h goes up to 360) and this makes it inconvenient to use in other tools that would prefer more of a 0 to roughly 1 normalization.
  2. The more conventional channel layout is for hue to be first and lightness to be last. For example, the existing conversions to HSV and HSY use that channel layout.

Currently, in order to use the existing RGB_TO_JMH with the GradingHueCurveTransform, I need to put a matrix on either side to rescale and reorder the channels. My proposal would be to create a new function that is ordered hMJ and has h divided by 360 and J divided by roughly 500.

Similarly, my only concern about the others is whether the inputs/outputs are normalized in a way that is convenient.

As we are currently developing LMTs that may work in JMh, it would be helpful if the optimizer was able to decompose an ACES_OUTPUT_TRANFORM into one or more fixed functions that expects JMh (from an LMT) as input so that a pair of RGB_TO_JMH and JMH_to_RGB could be dropped. Currently, is it possible to replace an ACES_OUTPUT_TRANSFORM with RGB_to_JMH + TONESCALE_COMPRESS + GAMUT_COMPRESS + JMH_to_RGB?

Tagging @KevinJW and @remia for input.

Note: When implementing this, search Config_tests.cpp for "experimental" and clean up accordingly. Likewise remove "experimental" from OpenColorTypes.h fixed function descriptions.

Lenguaje dominante
C++
Estrellas
2.1k
Forks
503
Merge medio
6 d 3 h
PR fusionados (30 d)
6

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de AcademySoftwareFoundation/OpenColorIO

Todos los issues de AcademySoftwareFoundation/OpenColorIO

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.