Added fatal_error for incorrect block_size value in detect_color_card

[tj-schultz]

Describe your changes Added logic to check for incorrect block_size values to pass to cv2.adaptiveThreshold inside detect_color_card. Throws a fatal_error if not odd or greater than 1.

Type of update

• New feature or feature enhancement

Associated issues #1426

Additional context Documentation was left unchanged for simplicity. Could still be described in detect_color_card docs.

For the reviewer See this page for instructions on how to review the pull request.

• [ ] PR functionality reviewed in a Jupyter Notebook
• [x] All tests pass
• [x] Test coverage remains 100%
• [x] Documentation tested
• [ ] New documentation pages added to plantcv/mkdocs.yml
• [ ] Changes to function input/output signatures added to updating.md
• [ ] Code reviewed
• [ ] PR approved

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.98%. Comparing base (ec2e2df) to head (9aee9cd).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1457   +/-   ##
=======================================
  Coverage   99.98%   99.98%           
=======================================
  Files         159      159           
  Lines        7048     7050    +2     
=======================================
+ Hits         7047     7049    +2     
  Misses          1        1           

Flag	Coverage Δ
unittests	99.98% <100.00%> (+<0.01%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
plantcv/plantcv/transform/detect_color_card.py	100.00% <100.00%> (ø)

[HaleySchuhl]

Thanks for opening this Pull Request @tj-schultz. I think the informative fatal error is a good way to handle this, as more information in the doc page for a totally optional parameter could be a distraction.

For some reason, DeepSource is complaining about the level of complexity being too high for this function now. Not sure how they are calculating this as this function looks far less complex than others in this package. Also not sure it's something worth addressing, since I'd consider the functionality well documented and easy enough to edit as is.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.98%. Comparing base (a5ede9b) to head (9aee9cd). Report is 219 commits behind head on main.

:exclamation: Current head 9aee9cd differs from pull request most recent head e8225c5. Consider uploading reports for the commit e8225c5 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1457      +/-   ##
==========================================
- Coverage   99.98%   99.98%   -0.01%     
==========================================
  Files         161      159       -2     
  Lines        7066     7050      -16     
==========================================
- Hits         7065     7049      -16     
  Misses          1        1              

Flag	Coverage Δ
unittests	99.98% <100.00%> (-0.01%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
plantcv/plantcv/transform/detect_color_card.py	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

[deepsource-io[bot]]

Here's the code health analysis summary for commits 7103e06..e8225c5. View details on DeepSource ↗.

Analysis Summary

Analyzer	Status	Summary	Link
Python	✅ Success		View Check ↗
Test coverage	⚠️ Artifact not reported	Timed out: Artifact was never reported	View Check ↗

---

💡 If you’re a repository administrator, you can configure the quality gates from the settings.

[tj-schultz]

It appears that the Test Coverage artifact cannot be reported from DeepSource as the introduction of the failing metric is preventing the merging of this PR.

There also appear to be other cyclomatic complexity threshold risks in the existing plantcv source for other functions. json2csv, segment_insertion_angle, etc. One solution for this PR and perhaps to address these other instances would be to manually set the threshold for the project. From DeepSource:

Cyclomatic complexity threshold can be configured using the cyclomatic_complexity_threshold meta field in the .deepsource.toml config file.

This would be a decision for the entire project and is larger than the scope of this PR, but could make it easier to amend existing components in the future.