Changes between Version 14 and Version 15 of appsDiscuss

02/12/2008 03:30:54 PM (11 years ago)



  • appsDiscuss

    v14 v15  
    33from: [wiki:DC3Management DC3 Management] 
    5 vw: RHL has questioned whether we want to continue to use VisualWorkbench. 
     5vw: RHL has questioned whether we want to continue to use !VisualWorkbench.  (RHL) I don't think that we're gaining much from it, and I find the bits that we are using (pixel accessors) too limited for my applications. If we do stick with vw, then I think that we should inherit from the image classes, not require the user to follow a pointer to get to the vw objects --- this is a classic IsA relationship. 
    2222fw::image classes (Mask, Image, MaskedImage, and in some cases Exposure): 
    2323 - Fix python versions of +=, etc. (ticket #244) 
    24  - An efficient way to copy image data to and from numpy arrays would help unit tests  (comment by Russell Owen) 
     24 - An efficient way to copy image data to and from numpy arrays would help unit tests  (comment by Russell Owen). N.b. the hard part of this is making python Images and Masks behave as numpy arrays;  this is doable (I did it in swig 1.3.27 for ACT), but the implementation got broken by some swig change.  This is scary.  RHL. 
    2525 - Need unit tests 
    2626 - subimage metadata needs some work. FITS files written from subimages have incorrrect headers (or at least are not usable by ds9 -see ticket #302). I'm not sure if there are any issues with subimages being persisted in other ways. (comment by Russell Owen) 
    2727 - Handle FITS metadata more gracefully. For example at present an Image and a MaskedImage read from a FITS file have the all the fITS header data as metadata. But that medata is not updated if a subimage is taken. Similarly an Exposure read from a FITS file has WCS information in the FITS metadata and in the WCS object. 
     28 - (RHL)  The subimage model is, I think, probably wrong.  At present, a subimage is a COPY of an image, not a pointer into the same object. This makes it impossible to write code that e.g. builds a mosaic.  I'd like to see copies to be deep, and use subimage explicitly to get shallow copies.  I find the current situation confusing. 
     29 - (RHL) Handle image offsets consistently.  This is quite hard, and I don't know a good OO way to do it --- basically, pixel manipulations don't seem to map to OO very well.  An example is that the detection::Footprint code needs to set the Footprint's coordinate systems allowing for the image's origin. 
     30 - (RHL) We need to make the iterators much more powerful, allowing relative subscripting. 
    3740 -  Standardize on int or unsigned int for all of  the following (comment by Russell Owen): 
    3841   - Setting cols and rows in constructors (int in Mask, Image but not Kernel or vw) 
    39    - getCols/getRows (always unsigned now) 
     42   - getCols/getRows (always unsigned now) RHL and a pain -- I usually end up casting it away. 
     43 - RHL Be consistent about our "left" and "right" conventiontions (e.g. do we want to follow the vw convention that bbox.max().x() is one after the last pixel?).  My vote is "yes", but this involves changes to e.g. detection::Footprint.