| 25 | | Plan A is much easier to implement in the context of normal IPP operations. |
| | 25 | Plan A is much easier to implement in the context of normal IPP operations because the ultimate source of all pixels the raw images will have streaks removed. (The excised pixels will be saved in |
| | 26 | separate image files). |
| | 27 | |
| | 28 | We have done some experiments running de-streaked chip processed images through warp and difference processing. There are some differences between the results and the original runs including the streak pixels |
| | 29 | |
| | 30 | * Areas that were not included in the magic streak detection phase were masked |
| | 31 | * The masked areas of the streaks were widened somewhat TODO: quantify |
| | 32 | |
| | 33 | Implementation of Plan B would require several enhancements to the IPP and operations |
| | 34 | |
| | 35 | * excised pixels from destreaking would need to be saved at all stages (deleted during cleaning) |
| | 36 | * psModules would need the ability recreate the original image by merging the excised pixels with the de-streaked image |
| | 37 | |
| | 38 | === Specific Implementation Tasks === |
| | 39 | |
| | 40 | ==== *Run.magicked *file.magicked values ==== |
| | 41 | |
| | 42 | Currently when an image file is de-streaked the column 'magicked' in the corresponding database table is set to the magic_ds_id value of the corresponding magicDSRun. If this value is non-zero, the image has been destreaked and thus can be sent through the distribution system or used as input to postage stamp requests. When destreak processing is finished for the entire run the Run's magicked bit is set as well. |
| | 43 | |
| | 44 | In the case where say a chipProcessedImfile is updated using a destreaked raw image we'd like to propagate the value from the rawImfile. However this is the magic_ds_id of the run that destreaked the raw file. It doesn't make much sense to use that value in the chip run's data. |
| | 45 | |
| | 46 | We will replace those values with the magic_id of the magic streak detection run that generated the list of streaks that were removed from the image. This will be consistent in all cases. |
| | 47 | |
| | 48 | The magicked column needs to be managed properly through the cleanup and update process. Currently the value is unchanged when the run is cleaned. It is zeroed when the magicDSRun is cleaned up. |
| | 49 | The magicDSRun controls the destreak process and the associated magicDSFile table contains the location of the backup and excised pixel images. This is a bug since nothing enforces that the magicDSRun's be cleaned up. |
| | 50 | |
| | 51 | We propose that when a run with 'magicked > 0' is cleaned up, the value is set to -1. Tests in the system that check destreaked status will need to be changed |
| | 52 | |
| | 53 | |
| | 54 | {{{ |
| | 55 | from |
| | 56 | if magicked |
| | 57 | to |
| | 58 | magicked > 0. |
| | 59 | }}} |
| | 60 | |
| | 61 | |
| | 62 | During update processing the check for the status of the inputs will be changed |
| | 63 | |
| | 64 | {{{ |
| | 65 | from |
| | 66 | |
| | 67 | *Run.state = 'full' |
| | 68 | |
| | 69 | to |
| | 70 | |
| | 71 | (*Run.state = 'full' and *Run.magicked >= 0) |
| | 72 | |
| | 73 | }}} |
| | 74 | |
| | 75 | This allows runs which have been cleaned but not yet magicked to updated. |