Added the histogram equalization operator#72
Conversation
|
@ivantha I’ve implemented the Histogram Equalization operator as discussed in issue #41. The backend and frontend changes have been completed and validated locally. Please let me know if any improvements or additions are required. It appears that merging is currently blocked due to required Code Scanning checks not running for this PR. Kindly let me know if any action is needed from my side. |
ivantha
left a comment
There was a problem hiding this comment.
Lgtm 👍🏼 Please rebase the PR to merge.
|
Rebased onto the latest main. The branch is up to date and ready for merge. Please let me know if anything else is required. Thanks ! |
|
@AbhaBarge, looks like we have conflicts due to the earlier PRs that were merged. Could you please rebase once again? Thanks |
|
Hi @ivantha I've rebased again onto the latest main. The branch is now ready for merge. Please let me know if anything else is required. Thanks ! |
|
I am still seeing conflicts. |
ivantha
left a comment
There was a problem hiding this comment.
◎ Argus Review
This PR adds a Histogram Equalization operator to the backend (Python/OpenCV) and a corresponding Blockly block on the frontend. The backend implementation is mostly sound and follows existing patterns, but contains a potential runtime crash for non-uint8 images and silent failure for unsupported channel counts. More critically, the frontend changes contain multiple syntax errors — a missing comma in categories.ts and duplicate tooltip properties (plus a missing comma) in conversions.blocks.ts — that will prevent the frontend from compiling. These bugs appear to stem from a bad cut/paste operation when inserting the new block definition. No automated tests were added for the new operator.
|
@ivantha I’ve rebased the branch on the latest main, resolved merge conflicts, and addressed the backend and frontend lint issues. The workflows appear to be awaiting maintainer approval. Please approve. |
|
Please fix lint errors. |
|
@AbhaBarge and sqush all the commits into one. |
9e4600c to
5c7efd1
Compare
@ivantha I got the issue. Locally I was only running the Ruff lint checks and hadn’t verified the formatting step (ruff format --check), which is enforced in CI. I’ve now reformatted the two affected files and pushed the changes. Apologies for the oversight. The linting and formatting issues should now be resolved. Please let me know if anything else needs attention. |
PR ReviewRebaseMerge commits detected — please use rebase instead of merge: SquashYour PR has 2 commits. Please squash into a single commit. How to fixgit fetch origin
git rebase -i origin/main # mark all but first commit as "squash"
git push --force-with-leaseThis comment updates automatically on each push. |
e83553a to
2bafa4b
Compare
|
@ivantha Please check. All the issues have been resolved now. I apologise for the immense delay. Thank you for your patience, I learnt a lot while working on this single PR ! |
|
Reviewed. Adds a HistogramEqualization operator (grayscale via equalizeHist, color via Y-channel in YCrCb) wired through the backend registry and a Blockly block in the Conversions category. PR also includes some incidental changes (kernelSize validation on morphological, formatting tweaks in color.py, shortened colortobinary tooltip) which overlap slightly with other in-flight PRs but are benign. Merging via rebase. |
|
Attempted rebase-merge but GitHub reports the branch can't be rebased cleanly (likely because of non-linear history or a merge commit on the PR branch). Could you rebase this branch onto the latest main locally and force-push? I'll re-attempt the merge afterward. |


Description
Implemented the Histogram Equalization operator for both backend and frontend.
On the backend, a new HistogramEqualization operator was added under the conversions module, following the existing BaseOperator pattern. The operator applies cv2.equalizeHist() for grayscale images and, for color images, performs equalization on the luminance (Y) channel in YCrCb space to preserve color fidelity. It requires no parameters and has been registered in registry.py to integrate with the processing pipeline.
On the frontend, a corresponding Blockly block was added under the Conversions category with no parameter fields, fully integrated into the existing pipeline flow.
The implementation has been validated using standard and low-contrast grayscale and color images, confirming improved contrast and compatibility with downstream operators.
Fixes #41
Type of Change
How Has This Been Tested?
Describe the tests you ran to verify your changes.
Screenshots (if applicable)
Checklist