mirror of
https://github.com/infiniflow/ragflow.git
synced 2026-07-12 14:45:42 +08:00
0ee02fb6d8
Fixes #7316. ## Problem `deepdoc/vision/operators.py` defines the image-standardize preprocessing op as `class StandardizeImag` (missing the final `e`), but every caller — including `deepdoc/vision/recognizer.py::Recognizer.preprocess` — looks the class up by the canonical string `"StandardizeImage"` via: ```python op_type = new_op_info.pop("type") # "StandardizeImage" preprocess_ops.append(getattr(operators, op_type)(**new_op_info)) ``` So `getattr(operators, "StandardizeImage")` raised `AttributeError`, and the "StandardizeImage" preprocessing step silently never ran for any image pipeline that used the dynamic dispatch (LayoutLMv3 and friends). The user-visible symptom is that the standardize step is missing entirely from the preprocessing chain, so the model gets un-normalized images. ## Production fix ```diff -class StandardizeImag: +class StandardizeImage: """normalize image Args: mean (list): im - mean std (list): im / std is_scale (bool): whether need im / 255 norm_type (str): type in ['mean_std', 'none'] """ ``` That's the entire production change — a one-character class rename. The misnamed `StandardizeImag` had no other references in the codebase (verified via `git grep`), so removing it is safe; every caller uses the canonical `"StandardizeImage"` string and will now resolve correctly. ## Tests New `test/unit_test/deepdoc/vision/test_operators_standardize_image.py` with six regression tests, all green locally: ``` test_standardize_image_class_resolves_by_canonical_name PASSED test_standardize_image_callable_matches_legacy_alias_name PASSED test_standardize_image_normalizes_input_with_mean_std_and_is_scale PASSED test_standardize_image_skips_scaling_when_is_scale_false PASSED test_standardize_image_norm_type_none_passes_image_through PASSED test_standardize_image_via_module_getattr_dispatch_path PASSED 6 passed in 0.18s ``` The tests: 1. **Pin the dispatch contract** (`hasattr(operators, "StandardizeImage")`) — this is the exact check the recognizer's `getattr` would do, so any future regression fails the same way the runtime would. 2. **Pin that the misspelled name is gone** — if a downstream caller ever relied on it, this fails loudly. 3–5. **Behavioural coverage** of the three documented code paths: `is_scale=True, norm_type="mean_std"`, `is_scale=False, norm_type="mean_std"`, and `norm_type="none"`. 6. **End-to-end via the same `getattr(operators, "StandardizeImage")` call** the recognizer uses, with a real numpy image, so any rename or removal surfaces as `AttributeError` instead of silently skipping the step. Verified both ways: - Without the fix → **all 6 tests fail** (Python even suggests `'StandardizeImag' → 'StandardizeImage'`) - With the fix → all 6 pass in 0.15s The test file follows the project's existing pattern (`test/unit_test/deepdoc/parser/test_html_parser.py`): load the target module via `importlib.util.spec_from_file_location`, stub the only project-internal import (`rag.utils.lazy_image`), and assert against the loaded module — no full RAGFlow runtime required. ## Risk Very low. The class is renamed; no public Python API was using the misnamed class. The only reference path is the `"StandardizeImage"` string in `recognizer.py:270`, which now resolves correctly. ## Out of scope - No other ops in `operators.py` are affected; checked all the others (DecodeImage, NormalizeImage, Permute, etc.) and they all use correct names. - The dynamic-dispatch lookups in `recognizer.py` for `LinearResize`, `StandardizeImage`, `Permute`, `PadStride` all use the same dispatch path; only the `StandardizeImage` key was broken. No other keys need fixing. Made with [Cursor](https://cursor.com) --------- Co-authored-by: Taranum01 <Taranum01@users.noreply.github.com> Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Zhichang Yu <yuzhichang@gmail.com>