| 1 | Diagnosing differences between new merging (rev.[770]) & Duchamp-1.1.10 |
|---|
| 2 | 2010/12/15 |
|---|
| 3 | |
|---|
| 4 | Using Tara's tests from before 1.1.10's release, we see some differences, with some pixels appearing in the new results that are *not* in the old. These pixels (eg. 75,409,135) are the result of growing, and so are not originally detected. |
|---|
| 5 | |
|---|
| 6 | To simplify things, we look at no-growing. Then we see a different number of detections - I have set all minimum sizes to 1 so that we don't lose anything. |
|---|
| 7 | |
|---|
| 8 | The pixel (61,409,127) is recorded as a single-pixel detection in 1.1.10, but is merged into object #1 with the new stuff. Thus, it seems to be a slight difference in how the merging thresholds are interpreted. |
|---|
| 9 | |
|---|
| 10 | Need to find what pixel(s) this pixel gets merged with in the new case, and why that doesn't happen in 1.1.10. |
|---|
| 11 | Candidates (looking at the log list, with no intermediate merging): |
|---|
| 12 | * 14 59.5 413.8 122.0 14.367 0.378 1.37 56 64 408 418 122 122 45 1 45 |
|---|
| 13 | * 15 59.0 415.1 123.0 15.739 0.469 1.70 55 63 412 419 123 123 46 1 46 |
|---|
| 14 | * 17 58.5 414.2 124.0 15.870 0.394 1.43 54 63 410 419 124 124 49 1 49 |
|---|
| 15 | * 18 58.8 414.8 125.0 20.122 0.430 1.56 54 65 410 419 125 125 61 1 61 |
|---|
| 16 | * 25 57.5 413.1 129.0 12.543 0.386 1.40 54 61 408 417 129 129 39 1 39 |
|---|
| 17 | * 27 57.6 412.5 130.0 16.937 0.501 1.82 54 62 406 416 130 130 48 1 48 |
|---|
| 18 | * 29 58.9 413.9 131.0 27.073 0.463 1.68 53 65 409 419 131 131 78 1 78 |
|---|
| 19 | * 30 57.1 412.9 132.0 16.919 0.442 1.61 54 62 407 418 132 132 49 1 49 |
|---|
| 20 | * 31 57.7 413.5 133.0 20.182 0.430 1.56 53 64 409 418 133 133 59 1 59 |
|---|
| 21 | * 32 56.8 413.1 134.0 14.063 0.458 1.66 54 60 410 417 134 134 41 1 41 |
|---|
| 22 | |
|---|
| 23 | So, a lot. We need to look in detail at all of these though to see exactly which pixels in each 2D object are present. |
|---|
| 24 | |
|---|
| 25 | Found the problem - the length of the scans in the new isClose function for Object2D was being misinterpreted (ie. was wrong). In looking at whether two scans were touching, the xmax value was overstated by 1 pixel, leading to the occasional erroneous match. |
|---|
