Opened 13 years ago

Closed 13 years ago

#99 closed defect (fixed)

Growing very inefficient

Reported by: MatthewWhiting Owned by: MatthewWhiting
Priority: highest Milestone: Release-2.0
Component: Searching Version: 1.1.9
Severity: normal Keywords:
Cc:

Description

The way the growing works is very inefficient. It does not pay any heed to whether a pixel is already detected in another object, but, even worse, each pixel in and around an object will be examined many times.

This was raised as an issue by Tara when looking at some GASS cubes. She suggested (based on her software) an approach where each pixel in the image has a flag associated with it indicating whether it is detected, queued to be checked, etc.. This could be adapted for Duchamp by having an array for the image that has a set of flags for each pixel - available, blank, detected, MW, ... (? any more?)

The growing function would then look at this and only proceed for a given pixel if it is available. It should also be able to update the cube's flag array so that subsequent calls to the growth function by other objects will use the updated version.

Change History (4)

comment:1 Changed 13 years ago by MatthewWhiting

Status: newassigned

An initial step to look at this could be to make an "ObjectGrower?" class that populates such a flag array initially.

It would have an initialisation function that takes the cube and populates the flags according to the detected objects (and BLANKs and MW channels). It would then operate on each object separately, growing it and updating the flag array.

Developing it this way would perhaps be safer than straight-away incorporating into the Cube class.

comment:2 Changed 13 years ago by MatthewWhiting

ObjectGrower class added in [742]. Still to actually make use of it.

comment:3 Changed 13 years ago by MatthewWhiting

Woo - implemented in [744] and see a massive speed-up. Running Tara's GASS cube now takes ~4min compared to many hours for the v1.1.9 code. Additional changes needed were tweaks to the Object2D::addPixel function, so that it only looks at relevant scans when trying to merge scans that have grown into each other (profiling with Shark showed this was a great sink of time...)

comment:4 Changed 13 years ago by MatthewWhiting

Resolution: fixed
Status: assignedclosed

The test case above is now down to 51s or so! Some profiling led to fixes in a few areas that cut out unnecessary computation (particularly removing the sorting in the Object2D::addPixel function).

Happy enough to close this ticket now.

Note: See TracTickets for help on using tickets.