CV Get CCM Loss

When you fit a colour-correction matrix from a ColorChecker chart, "does this look better?" is a bad question - you've just moved every colour in the image, so of course it looks different. The loss is the quantitative answer: the residual between what the chart's patches measured and what the reference chart says they should be, under the distance metric you chose. Lower is better.

This node reads that value out. It's one of five in the ccm family of bmad4ever's ComfyUI CV (bmad4ever/comfyui_cv, a fork of Gerold Meisinger's opencv-comfyui), wrapping cv2.ccm - a contrib module, and a class-based API the pack's auto-generated raw cv2.* wrappers can't express.

The node

One input: ccm_model, the fitted model socket that comes out of CV Create CCM Model (it takes the detected patches from CV Detect Color Checker). One output: loss, a float.

That's the whole thing. It's deliberately dumb, and it exists because of how you want to use the model: CV Create CCM Model already emits the loss and the matrix alongside the fitted model, but the fitted model is what travels down the wire and gets reused. Reading the loss off a model you received rather than fitted is the case this covers - and the same is true of CV Get CCM Matrix next door.

What the number is actually for

Calibrating a camera isn't the big use here. Comparing fits is. Fitting the same patches with a different ccm_type (linear 3×3 versus affine 4×3 with offset), a different distance metric (CIE2000 is the most perceptually accurate of them; the others are cheaper and coarser), or a different linearization gives you several candidate models and one defensible way to pick between them: run the fit, read the loss, keep the lower one. Two inspect nodes side by side, done.

Two honest caveats, both of which will bite if you forget them:

The loss is measured on the patches, not on your image. It says how well the matrix maps the chart's 24 (or 18, or 140) measured patches onto their reference values. A model that fits the chart beautifully can still look wrong on a photograph, because the transform was fit on saturated chart colours rather than on your scene's distribution. The loss is a filter for bad fits, not a guarantee of a good result - nothing beats looking at the output.

It isn't comparable across different patch counts or chart types. A DigitalSG 140-patch fit and a Macbeth 24-patch fit are different sums over different data. Compare like with like; the chart type you detected has to match the reference set the fit used, or every number in the comparison is meaningless.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv
pip install "opencv-contrib-python-headless~=5.0.0.93"

Or search ComfyUI CV in ComfyUI Manager. Python ≥ 3.12 and a V3-API ComfyUI.

One install trap worth knowing, because it silently kills exactly this family: the pack depends on the contrib OpenCV wheel (opencv-contrib-python-headless). opencv-python and opencv-contrib-python share one site-packages/cv2, so installing a non-contrib wheel over it empties the contrib submodules - and cv2.ccm and cv2.mcc are contrib. The nodes vanish rather than error. tools/repair_opencv_contrib.py --check diagnoses it.

Common issues

Import error on cv2.ccm. Wrong OpenCV wheel. See above.

The loss is enormous and the chart "detected" anyway. CV Detect Color Checker found a chart-shaped thing that isn't your chart, or the chart type is mismatched to the one in the photo. Check found from the detector and the patch count before trusting anything downstream.

Loss improved but the image didn't. Read the first caveat again: you optimised patch residuals, not the picture. If the image still disagrees with reality, the problem is usually upstream - white balance, exposure, or the patches being clipped.