Ticket #145 (closed task: fixed)

Opened 9 years ago

Last modified 8 years ago

Assist in devleopment of ImgLibProcessor

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: biweekly-2010: Sep-07 to Sep-17
Component: Core Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking: #1014

Description (last modified by bdezonia) (diff)


Change History

comment:1 Changed 9 years ago by bdezonia

  • Status changed from new to assigned

comment:2 Changed 9 years ago by bdezonia

  • Status changed from assigned to accepted

comment:3 Changed 9 years ago by bdezonia

Worked on flipVertical(), snapshot routines, and applyTable().

comment:4 Changed 9 years ago by bdezonia

Worked on Snapshot class code
Began integration into imglibProcessor

comment:5 Changed 9 years ago by bdezonia

Further work on method implementation. Creation of ImgLibProcessorTest. Debugging of existing methods. Implementation of some test methods (doing TDD at this point).

comment:6 Changed 9 years ago by bdezonia

Hatched multiple support and test classes. Continued implementation. At the moment testing versus ByteProcessor. Approximately 60 methods done and testing okay. Fourteen remaining methods versus ByteProcessor. Float/Short Processor support will probably involve changes to another 15 methods.

comment:7 Changed 9 years ago by bdezonia

All methods for ImageProcessor compatibility for type byte in place and passing all tests. Much test code developed. Multiple refactorings done.

Currently extending the tests to exercise short type data and fixing ImgLibProcessor as needed along the way. Then will need to do the same for float data.

ImgLibProcessor will need additional refactoring when byte/short/float data all passing tests as older code just pasted in and modified from ImageJ's processor classes.

comment:8 Changed 9 years ago by bdezonia

All methods implemented for Byte, Short, and Float processor compatibility. The Float code is not exactly the same but all points within a 0.001 tolerance. The reason it differs is because for generality we calculate every FloatProc method in double precision and IJ was using floats in a few cases. If we need exact same results then we will need to break out special case code for FloatType in ImgLibProcessor. Loses generality and results in code bloat.

The implementation of the methods involved a lot of cutting and pasting from the existing processors and then applying modifications. The code needs commenting (especially the classes that have resulted from some refactoring) and additional refactoring needs to take place.

comment:9 Changed 9 years ago by bdezonia

  • Description modified (diff)

comment:10 Changed 9 years ago by bdezonia

  • Description modified (diff)

Some more refactoring done for copyBits(). It would be nice if we could refactor away the special case code for concolve3x3(). It would be good to refactor code so that we've generalized the various filters.

comment:11 Changed 9 years ago by bdezonia

  • Status changed from accepted to closed
  • Resolution set to fixed

Will start documenting steps as separate tickets from here on out.

comment:12 Changed 8 years ago by curtis

  • Blocking 1010 added

comment:13 Changed 8 years ago by curtis

  • Blocking 1014 added; 1010 removed
Note: See TracTickets for help on using tickets.