MadVR TUTORIAL (14/01/22 Actualizado!) Tone mapping dinámico.

Ahora mismo es lo que más espero, una versión de madvr que realmente se pueda usar para la conversión de forma fiable y efectiva.

He seguido el hilo de avs y la verdad que nunca había visto a madshi trabajar tanto y con una relación tan estrecha con la comunidad, es obvio que la conversión es muy importante para él, incluso diría que es un paso fundamental para poner a la venta el madvr.
 
El plan de madshi es ponerlo a la venta tan pronto llegue a la versión 1.0, ese ha sido su plan desde el inicio, de hecho yo hablé con él por privado en doom9 porque quería hacerle una donación por su trabajo y fue él mismo que me confirmó que lo pondría a la venta y que yo debía esperar a esa fecha para comprarlo, que de momento no aceptaba donaciones.

Igual cambia de opinión y lo mantiene siempre gratis, pero su idea siempre ha sido venderlo cuando esté "completo".
 
Yo creo que una cosa es decir que lo quiere vender y otra montar la infraestructura para vender. Además, un producto se pone a la venta cuando cubre una cierta necesidad y no cuando es perfecto. En caso de existir esa necesidad, puede que ya haya desaparecido para cuando la comunidad lo considere perfecto o que el producto "casi perfecto" esté tan extendido que nadie lo compre, máxime tratándose de un producto tan de nicho con un mercado potencial tan pequeño. P?ero vamos ... es sólo mi opinión.
 
En realidad tu comentario ha sido un pretexto para comentar algo que pensaba desde hace tiempo y tienes razón, por supuesto, que lo que he comentado, son conjeturas.
 
Yo creo que debería pedir una donación voluntaria y los que paguen un poco reciban las actualizaciones antes o algo así.

Se ha puesto de moda en algunos ámbitos para apoyar al desarrollador sin llegar a convertir el software en exclusivamente de pago.
 
King Conan dijo:
Yo creo que debería pedir una donación voluntaria y los que paguen un poco reciban las actualizaciones antes o algo así.

Se ha puesto de moda en algunos ámbitos para apoyar al desarrollador sin llegar a convertir el software en exclusivamente de pago.
Hacer clic para expandir...
Me parece una buena idea. Se lleva haciendo hace mucho tiempo en divérsos ámbitos.
 
* HDR: improved overall tone mapping quality * HDR: added "color tweaks for fire & explosions" option * HDR: "restore details in compressed highlights" renamed to "highlight recovery" * HDR: improved "highlight recovery" algo, now uses/requires DirectCompute * HDR: added trade quality option "compromise on tone & gamut mapping accuracy" * HDR: maxCLL is now used (if valid) * HDR: added "hdrVideoPeak" profile variable * HDR: added (limited) support for HDR OSD bitmaps * added "report BT.2020 to display" calibration option * added true GPU mode info (color format, bitdepth & dynamic range) to OSD (Nvidia only) * fixed: low latency mode could result in judder/stuttering * fixed: OSD API sometimes drew stuff in the wrong position * fixed: madHcNet32/64.dll produced DCI-P3 3DLUTs with incorrect header * added undocumented "ShowHdrMode" empty file/folder option

Mucha tela aquí, ya contarás ajustes básicos, yo hasta mañana no podré mirarlo.
 
Madre mía cada vez se complica más, pronto el inem impartirá cursos avanzados de como configurar el madvr.

Todo ese tema del hdr me supera por completo, y mira que soy de cacharrear, pero tantas opciones es una locura, espero que en una versión futura lo simplifique un poco y lo haga más intuitivo.
 
Es igual que antes realmente, hay poco que configurar en el hdr.

He tenido la ocasión de comparar esta última versión con la gamma de jvc st2084 de un 7900 y tengo que decir que la gamma del jvc trabaja realmente bien.

Tal vez el madvr saca algo más de detalle en las luces pero el jvc tiene un poquito más de efecto hdr.

Saludos
 
La primera prueba es positiva. Incluso ha bloqueado los valores por defecto de ajuste de conversión (hay que desmarcar una casilla bastante escondida para desbloquearlo).

Mañana intentaré poner alguna captura.

@Axelpowa ¿estás al tanto que ajustes se recomiendan en los highlights y demás?

En target nits tengo puestos 300.
 
Si, hay que quitar la opción en Trade Quality for Performance.

Yo uso en ambas opciones high y high. La opción de Measure each frame marcada, fundamental.

El peak nits lo tengo en 250, pero he bajado la gamma en display calibration a 2.2. Esto fue sugerencia de Ramón y la verdad que muy bien.

Tiene mas punch la imagen así a mi gusto en los colores.

Saludos!
 
Perfecto, yo antes tenía puesto 280 nits, trataré de afinar.

Y en el JVC qué valores tienes de gamma?

Estás usando RGB 12 bits en la Nvidia y 0-255 en madvr?
 
¿Y teóricamente no hay que poner el rango completo en madvr también?

Yo tengo un buen nivel de negro así.

¿Dónde has visto que aconsejen el limitado en madvr?
 
Si se pone en madvr 0-225 aplastas los negros si o si ,
Por eso en madvr hay que poner salida en limitada ,
Si poner un patrón de brillo y todo a 0-255 verás que no ves nada de nada y tienens que subir muchísimo el brillo para llegar al target, en cambio con limitada no,
Como dice Axel , gamma 2.4 en jvc y en el madvr 2.2 te dará muy buen suelo de negro
 
A) Which output format (RGB vs YCbCr, 0-255 vs 16-235) should I activate in my GPU control panel?

Windows internally always "thinks" in RGB 0-255. Windows considers black to be 0 and white to be 255. That applies to the desktop, applications, games and videos. Windows itself never really thinks in terms of YCbCr or 16-235. Windows does know that videos might be YCbCr or 16-235, but still, all rendering is always done at RGB 0-255. (The exception proves the rule.)

So if you switch your GPU control panel to RGB 0-255, the GPU receives RGB 0-255 from Windows, and sends RGB 0-255 to the TV. Consequently, the GPU doesn't have to do any colorspace (RGB -> YCbCr) or range (0-255 -> 16-235) conversions. This is the best setup, because the GPU won't damage our precious pixels.

If you switch your GPU control panel to RGB 16-235, the GPU receives RGB 0-255 from Windows, but you ask the GPU to send 16-235 to the TV. Consequently, the GPU has to stretch the pixel data behind Windows' back in such a way that a black pixel is no longer 0, but now 16. And a white pixel is no longer 255, but now 235. So the pixel data is condensed from 0-255 to 16-235, and all the values between 0-15 and 236-255 are basically unused. Some GPU drivers might do this in high bitdepth with dithering, which may produce acceptable results. But some GPU drivers definitely do this in 8bit without any dithering which will introduce lots of nasty banding artifacts into the image. As a result I cannot recommend this configuration.

If you switch your GPU control panel to YCbCr, the GPU receives RGB from Windows, but you ask the GPU to send YCbCr to the TV. Consequently, the GPU has to convert the RGB pixels behind Windows' back to YCbCr. Some GPU drivers might do this in high bitdepth with dithering, which may produce acceptable results. But some GPU drivers definitely do this in 8bit without any dithering which will introduce lots of nasty banding artifacts into the image. Furthermore, there are various different RGB YCbCr matrixes available. E.g. there's one each for BT.601, BT.709 and BT.2020. Now which of these will the GPU use for the conversion? And which will the TV use to convert back to RGB? If the GPU and the TV use different matrixes, color errors will be introduced. As a result I cannot recommend this configuration.

Summed up: In order to get the best possible image quality, I strongly recommend to set your GPU control panel to RGB Full (0-255).
 
En teoría de esta forma hay menos procesos. Así llevo usando madvr desde hace mucho tanto para para BD como para la conversión HDR-SDR.

Salvo que haya cambiado algo durante el último año que se me haya escapado, claro.
 
Conéctate o regístrate para responder aquí
Arriba Pie