fix: preserve HME100k prediction case in OCRBench scoring

[akawincent]

Summary

• fix OCRBench scoring for the HME100k subset by preserving prediction case
• keep the existing lowercase normalization for the other OCRBench subsets unchanged

Why

Issue #1220 points out that ocrbench_process_results lowercases pred before branching on dataset_name, while the HME100k branch intentionally compares answers without lowercasing them. That makes correct HME100k predictions score as 0 when the only difference is letter case.

Testing

• not run (per request)

Closes #1220

[kcz358]

Hi, so instead of just remove the lower(), maybe should actually lower the gt_ans as well?

[akawincent]

Hi, so instead of just remove the lower(), maybe should actually lower the gt_ans as well?

@kcz358 I don't think we should lowercase gt_ans for HME100k.

HME100k should be case-sensitive, since it is handwritten mathematical expression recognition.

So, we should not lowercase pred, and we should not lowercase gt_ans either. The original problem was that pred was lowercased too early, which broke the intended HME100k matching behavior.

Since these answers are math-expression / LaTeX-like strings, lowercasing gt_ans could also create false positives for charactors like V, F, I, A, etc.

[kcz358]

Got it, looks make sense if HME requires the answer to be case sensitive. Will this change cause false negative on other branches? If not then I will merge this PR. Thanks

[akawincent]

@kcz358

No, this should not affect the other OCRBench branches.
I have confirmed that other branches do pred.lower() and gt_ans.lower() in else.... cuz they are case-insensitive.