Es que
-el modo sRGB no es sólo el blanco
-es absurdísima esa recogida de cable de tu mensaje, no, es contra un modo OSD frío. Mal, será contra el nativo o por defecto. Y puede venir mal no sólo en el eje b* (azul-amarillo, frio-calido) sino en el a*, magenta verde, que cuando viene mal de verdad un monitor es donde se nota. Ni calidez ni gaitas, si en a* está medio bien, aunque b* esté en 6700K CCT es perfectamente usable como monitor de ocio o como TV, "parece blanco" aunque sea mas frio que D65. De ahí que dijera y digo que no sabías ni lo que estabas diciendo, te sonaba lo de la calidez y si cuela cuela.
Respecto de tu pregunta, no conozco Calibrize, pero con la app A o B de calibración a ojo es siempre lo mismo:
-ajustar el blanco
-ajustar el gris, en color y brillo (gamma), creo que incluso la app de calibración a ojo de Windows 10 tenía 2 tonos grises para ajustar el color (como en el blanco, a ojo) y e brillo relativo de cada gris (gamma). No me acuerdo bien pero creo que sí tenía 2. Eso si ves alguna review de prad.de, se ve que tienen en el grafiquito de la escala de gris un "deltaC" (no E, C) muy alto, que el gris tiene colorines verdes o rosas respecto del color del blanco 255. Pues si te viene un monitor mal de colorines el en gris se corregiría a ojo así. Si pintas con alguna app un gradiente de negro a blanco canta enseguida, a ojo.
Y +- es lo que venías diciendo, si te he dicho que no me reí por eso y me parece muy bien que lo hagas a ojo, sino por el texto exacto que te cité.
Luego si la pantalla es widegamut como mucho monitor gamer con 90 y tantos % de cobertura P3, ahí para jugar, opcionalmente, se puede hacer 2 cosas porque en general (HDRs aparte) los juegos se diseñan pensando en pantallas sRGB:
-usar una app que lo autocorrija con los datos del EDID del monitor, como por ejemplo el driver de AMD o la app novideo_sRGB para nvidia. El monitor "debería" saber donde están sus primarios (las coordenadas de color) y lo informa a la GPU por los datos del EDID y estos programitas calculan full auto una transformación del espacio de color nativo a sRGB... pero sólo se pueden usar con los modos OSD que tengan el espacio de color nativo: el modo estandar, o juegos, o usuario, o personalizado o algo así, que generalmente tienen el espacio de color nativo. De lo contrario los datos EDID no corresponderian con el comportamiento real de ese modo OSD, por ejemplo el modo sRGB, y la transformación calculada sería errónea, te desatura de más.
o bien
-si el monitor tiene controles de saturación tratas de simular los primarios sRGB para juegos (realmente sólo tocas el R y G). Aquí se puede hacer a ojímetro con el PAINT, pintas un parche rojo 255 gordo y otro verde idem y tratas de dejarlo igual a alguna pantalla que tengas de referencia sRGB... por ejemplo si tienes un movil samsung amoled y lo pones en el modo "básico" (simulacion sRGB), si en una web dibujas R 255 o G 255 en el movil deberían ser +- rojo y verde 255 sRGB y te podrían servir de referencia si no tienes otro monitor fiable.
En ambos casos si "simulas" bien a ojo o bien en automatico un espacio de color mas pequeño que el nativo, ahi no puedes usar el perfil ICC del fabricante como perfil de pantalla en el SO, tienes que usar como perfil ICC lo que estás tratando de simular, sRGB en este ejemplo. Le dices así al SO y a las app con gestión de color que la pantalla ahora mismo se comporta como el perfil ideal que a ojimetro has tratado de simular via edid o los controles de saturación.
Si ese MAG274QRF-QD del OP es widegamut, y tiene pinta, debería hacer también esto último.
Si Calibrize tiene incorporado en sus parches de muestra para que corrija a ojo también la saturación, pues perfecto. Que no los trae, o lo que dije del Paint o aun mejor que use el novideo_sRGB para su nvidia y que lo haga en auto, pero si lo hace no puede hacerlo desde el modo sRGB.
