Verify HSV-Values of `load_image()` for rootarea & determine a method of discriminating against the background

[Claudius-Appel]

Currently, the background can not be discriminated against well in case of root-analysis

Reasons for this:

Well, the "uniform black" background currently used is a lot, but not black. and not uniform.
I actually don't really know how myrapla actually managed to do this, cuz so far it seems... optimistic.

[Claudius-Appel]

However, confusingly myrapla does exactly the same.

It calls, in order from top to bottom:

data.process_file() (app.py)
image = cv2.imread(file.as_posix()) (data.process_file)
image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB)
processing.mask_rgb_image() (data.py), with bounds `helpers.HSV_MASK_BOUNDS[plant_color_key]["lower"],helpers.HSV_MASK_BOUNDS[plant_color_key]["upper"]`
image_in_color_space_of_bounds = cv2.cvtColor(rgb_image, cv2.COLOR_RGB2HSV) (mask_rgb_image)
mask = cv2.inRange(
        image_in_color_space_of_bounds,
        lower_bound.representation,
        upper_bound.representation,
    )
processing.process_mask(mask,erode_iter,dilate_iter)  with iterations = 0/0, so we don't care abt this
return all the way to app.py

retrieve the largest contour only 

which, verbose, is the following:

1. get the path
2. load the image in bgr-format
3. convert bgr > rgb format
4. ...
5. perform an cv2.inRange()-check. This is simply just a boolean check across all 3 dimensions, e.g. the same I would do. For details, see https://docs.opencv.org/3.4/d2/de8/group__core__array.html#ga48af0ab51e36436c5d04340e036ce981
6. do not erode, do not dilate, because iterations are set to 0.
7. goes all the way to count all pixels matched in the entire mask. So there is no bounding on which hits are registrated - they all are.

SO:::

The only viable reason for why myrapla gets much fewer hits is that it checks all three elements of an HSV-pixel. I can only validate elements Hue and Saturation, as Value does not line up with the reported values of any of my external validators.

[Claudius-Appel]

Which leaves the question of... can I validate that the V-component is valid, so that I can define viable thresholds for it and read it in?

[Claudius-Appel]

Maybe check the density distribution of the roots? plot(density(V <- rootarray[,,,3], bw = "SJ"))

• write a new cpp-func that does include the V-comp into the which()-check
• determine which range of HSV values you actually must use for the damn fucking god forsaken roots.
• determine by trial and error which range of V-values should be used
• check results in D:\Dokumente neu\Repositories\duflor\dev\design\root_area_finetune for rudimentary decisionmaking on which ranges I should first proof for.
  

[Claudius-Appel]

We could reintroduce the value-parameter into the HSV-check again. From my understanding, this should be viable, but oly if there is a reasonable difference between fore- and background pixels.

This means:

Prepare a 20x20 pixelset with following quadrants

leaf | leaf-background
--------------------------
root | root-background

And check what the value-plane displays for them. There must be a significant gap between foreground and background pixels before we can consider re-introducing value-checking.

[Claudius-Appel]

Root-area:

Current best seems to be

spectrums <- list(
    lower_bound = list(
        bex_root_HSV = c(21.80, 0.30, 0.0099)
        , bex_identifier_dot = c(270, 0.2, 0.0099)
    ),
    upper_bound = list(
        bex_root_HSV = c(52,0.8,0.9)
        , bex_identifier_dot = c(359, 1, 1)
    )
)

However, this is still not perfect:

[1] "D:\\Dokumente neu\\Repositories\\Grünflächen-Utilities\\Excludes\\Testdata Root Analyses\\Testdaten Wurzeln\\Testbilder\\2023-10-26_BY-Penew_0,25_1.2(2).JPG" >

[1] "D:\\Dokumente neu\\Repositories\\Grünflächen-Utilities\\Excludes\\Testdata Root Analyses\\Testdaten Wurzeln\\Testbilder\\2023-10-26_BY-Penew_0,25_1.2(1).JPG" >