PaddlePaddle/PaddleOCR · error · NotImplementedError

{} is not supported in MultiLoss yet

Error message

{} is not supported in MultiLoss yet

What it means

MultiLoss (used by GTC-style recognition heads) iterates over configured loss names and only knows 'CTCLoss', 'SARLoss' and 'NRTRLoss'. Each branch pulls the matching prediction tensor from predicts['ctc']/'sar'/'gtc'; any other name raises NotImplementedError with the offending name.

Source

Thrown at ppocr/losses/rec_multi_loss.py:62

        # batch [image, label_ctc, label_sar, length, valid_ratio]
        for name, loss_func in self.loss_funcs.items():
            if name == "CTCLoss":
                loss = (
                    loss_func(predicts["ctc"], batch[:2] + batch[3:])["loss"]
                    * self.weight_1
                )
            elif name == "SARLoss":
                loss = (
                    loss_func(predicts["sar"], batch[:1] + batch[2:])["loss"]
                    * self.weight_2
                )
            elif name == "NRTRLoss":
                loss = (
                    loss_func(predicts["gtc"], batch[:1] + batch[2:])["loss"]
                    * self.weight_2
                )
            else:
                raise NotImplementedError(
                    "{} is not supported in MultiLoss yet".format(name)
                )
            self.total_loss[name] = loss
            total_loss += loss
        self.total_loss["loss"] = total_loss
        return self.total_loss

View on GitHub (pinned to 2661c7c0ef)

Solutions

1. Restrict names to exactly 'CTCLoss', 'SARLoss', 'NRTRLoss' in the MultiLoss config
2. Ensure the paired head actually outputs the keys the branch reads: predicts['ctc'], predicts['sar'], predicts['gtc']
3. For a new loss type, extend MultiLoss with an elif branch before the else (it is a small explicit dispatcher, not a registry)

Example fix

# before
loss_list = ['CTCLoss', 'NRTRLoss']  # NotImplementedError

# after
loss_list = ['CTCLoss', 'NRTRLoss']

MULTI_LOSS_NAMES = {'CTCLoss', 'SARLoss', 'NRTRLoss'}
for name in loss_list:
    assert name in MULTI_LOSS_NAMES, f'MultiLoss does not support {name!r}; use {sorted(MULTI_LOSS_NAMES)}'

def is_multi_loss_name(n: str) -> bool:
    return n in {'CTCLoss', 'SARLoss', 'NRTRLoss'}

When it happens

Trigger: Configuring MultiLoss with an unsupported name, e.g. MultiLoss(['CTCLoss','RCLoss']) or a typo like 'NRTRLoss' (case matters: the branch checks exact 'NRTRLoss'); also enabling SAR/NRTR loss without a head that outputs the corresponding key.

Common situations: Customizing a rec model with GTC loss and adding a loss the multi-loss wrapper doesn't dispatch on; case mismatch when porting config snippets between models.

Related errors

• The mode.lower() if KLJSLoss should be one of ['kl', 'js']
• main_loss_type in BalanceLoss() can only be one of {}
• [DBLoss]: Unrecognized main loss type!
• mode[{mode}_model] is not implemented!
• The mixer must be one of [Global, Local, Conv]

AI-assisted analysis of PaddlePaddle/PaddleOCR@2661c7c0ef (2026-08-14). Data as JSON: /api/errors/97b8689d0b89d295. Report an issue: GitHub.