Update PiTrac - Debugging and Code Walk-Throughs.md (#26)

Added image links

Documentation/PiTrac - Debugging and Code Walk-Throughs.md

@@ -30,15 +30,19 @@ In order to build on a non-Pi environment, you’ll need to setup a few things.
 3. Install Boost  
 4. Setup the Windows VS project to point to the correct include and library directories  
    1. In VS, go to Project/ImageProcessing Properties:  
-   2. ![][image1]  
+   2. ![image](https://github.com/user-attachments/assets/cf670299-aaa0-405b-849b-5c13e3043f29)
+
    3. Point to the correct libraries:  
-   4. ![][image2]  
+   ![image](https://github.com/user-attachments/assets/c0c19c80-51ae-4ecc-b84b-5436bf8a0dd1)
+
       1. For example, E:\\Dev\_Libs\\opencv\\build\\x64\\vc16\\lib\\\*d.lib;$(CoreLibraryDependencies);%(AdditionalDependencies)    \[NOTE \-The \*.d is for debug libraries.  If not debugging, then remove the “d”.  And do not mix \* and \*d \!  
    5. Point to the correct run-time binaries and libraries:  (and note that the suggested opencv instructions cited above do not use this step and instead copy files around (less desirable)  
-   6. ![][image3]  
+   6. ![image](https://github.com/user-attachments/assets/91633d86-a14b-41ab-9052-25cf97ac28de)
+
       1. For example, PATH=%PATH%;E:\\Dev\_Libs\\opencv\\build\\x64\\vc16\\bin  
 5. Setup the command-line parameters (for example):  
-   1. ![][image4]  
+   1.![image](https://github.com/user-attachments/assets/d3ba7ab7-e58d-400d-a15a-55221635c409)
+
    2. For example, the following is a good starting place for stepping through how the Pi1/Camera 1 system processes the golf ball images.   
       1. \--show\_images 1 \--lm\_comparison\_mode=0 \--logging\_level trace   \--artifact\_save\_level=all \--wait\_keys 1 \--system\_mode camera1\_test\_standalone  \--search\_center\_x 800  \--search\_center\_y 550   
    3. The above is a good setting for debugging, because the “--wait\_keys 1” will allow you to step through the intermediate debugging images by hitting any key to continue, but without having to step through all the code that creates those images. It’s useful to set a breakpoint just before where you think there’s a problem, and then let the program run, but sort of throttle the system by having the wait\_keys setting allow you to see what happened before that break point (at a high level).  
@@ -63,17 +67,22 @@ Let’s try a real-life example from a problem in a relatively brightly-lit test
 With those settings, a particular shot produced the following two image files in LM\_Shares/Images on the Pi’s was:
 
 log\_cam2\_last\_strobed\_img:  
-![][image5]  
+![image](https://github.com/user-attachments/assets/0178f125-92cd-4581-9210-0feb651d8fc2)
+
 ball\_exposure\_candidates:  
-![][image6]
+![image](https://github.com/user-attachments/assets/39bf3957-091f-4f27-8916-29b063d273fb)
+
 
 Spin\_ball\_1\_gray\_image1 and spin\_ball\_2\_gray\_image1:  
-![][image7]![][image8]	
+![image](https://github.com/user-attachments/assets/aab16121-265c-483a-89f1-4449de5988e8)![image](https://github.com/user-attachments/assets/7418212b-dd5e-4c16-aa76-7a725ef69353)
+
+
 
 You should also have an image of where the teed-up ball was, as this particular example is going to try to go through all the processing, including calculating where the ball was initially (and then, later, in comparison to the strobed balls.  A typical starting image is something like:  
 gs\_log\_img\_\_log\_ball\_final\_found\_ball\_img.png
 
-![][image9] (we often just reuse some old starting image if we’re just focused on debugging the strobed image processing.  
+![image](https://github.com/user-attachments/assets/da606a12-4906-4a7d-b06b-b530374f3104)
+ (we often just reuse some old starting image if we’re just focused on debugging the strobed image processing.  
 NOTE \- The teed-up picture does have some interaction with the downstream strobed-image processing.  The teed-up image gives the system an idea of how far from the monitor the ball is starting.  That Z-axis value is then used to choose a range of ball-radii to be looking for in the strobed picture.
 
 The strobed picture looks fairly solid, but at least two questions come to mind:
@@ -99,12 +108,15 @@ The following instructions are for Visual Studio 2022 in Windows, but should be
    4.   
 5. Set a break-point at the start of the testAnalyzeStrobedBalls() function and hit F5 to run.  
    1. NOTE \- You may have to do a little debugging to make sure the code gets to that function first.  
-   2. ![][image10]  
+   2. ![image](https://github.com/user-attachments/assets/d6f88d50-a284-446e-86bc-51e4d986d212)
+
 6. Another good place to put a break-point to start is here at bool GolfSimCamera::ProcessReceivedCam2Image  
-7. ![][image11]  
+7. ![image](https://github.com/user-attachments/assets/b5428bf5-812b-4694-a616-8ee8ab8289f8)
+
 8. After stepping through the Teed-up ball processing in GetCalibratedBall(), the system will start into the strobed image processing.  
 9. In our case, the initial identification ball circles (which uses a technique called Hough identification) results in the following:  
-10. ![][image12]  
+10. ![image](https://github.com/user-attachments/assets/9729d3aa-a744-4d9d-a19f-31ab2672c16b)
+
 11. This is ***not*** a good start.  It’s likely there will be some missed-ball identifications, such as those near the bottom of the screen (which should be filtered out later), but we may want to see if we can provide better settings to improve this starting point.  
 12. To help out debugging and tuning there are some “Playground” projects that we’ve created that allow a user to try out different settings for the Hough Circle Detection and other processes.  These are essentially copies of some of the pertinent code from the main project into a little project that is easier to manipulate.  
 13. To use the playgrounds effectively, you’ll first want to take the parameters that are being used in the PiTrac process that you’re debugging and then import those settings into the Playground so that you can, well, ‘play’ with them to figure out how to get a better result.  
@@ -127,7 +139,8 @@ Hough Circle Detection Playground:
 3. When you run the playground, several windows will come up, showing the pre-HoughCircles filtered image and the resulting identified circles.  This image should be identical to the image you would see in the main PiTrac code (assuming the Playground code is the same in relevant part).  
 4. At this point, you can try changing the code (in this case we changed the “HOUGH::GRADIENT” method to be “HOUGH::GRADIENT\_ALT” instead) moving the sliders in the control window to see what effect the altered parameters have on the results.  For our example, we found that changing the value of the “” helps a lot.  
 5. The result was:  
-   1. ![][image13]  
+   1. ![image](https://github.com/user-attachments/assets/787be451-5360-427f-98fc-5d484c8d936b)
+
 6. Finally, the new parameters are pushed into the golf\_sim\_config.json file to see how they work in the actual PiTrac LM.  Note that some of the values are scaled, such as the Hough Param2, which is 100 times smaller for the HOUGH::GRADIENT\_ALT method, and the DpParam1 which is always 10 times smaller.  
    1. "kStrobedBallsUseAltHoughAlgorithm": 1,  
    2.