CRISM Capstone Proposal
matlab | GUI | 代做mining | project | 代做Objective | Python | lab – 这是一个关于data mining的题目, 主要考察了关于data mining的内容,是一个比较经典的题目, 涉及了matlab/GUI/data mining/Objective/Python/机器学习等代写方面, 这个项目是lab代写的代写题目,关于分类器相关的内容
CRISM Capstone Proposal
Background: The Compact Reconnaissance Imaging Spectrometer for Mars, or CRISM, is an imaging device that has been placed aboard the Mars Reconnaissance Orbiter, or MRO, spacecraft and intends to scan roughly half of the red planet. The Objective of the CRISM project is to identify locations that are most likely to be a past or present source of water based upon the mineral composition of the region. This is done by scanning the surface using the CRISM module which utilizes 2 modes, targeted and untargeted, which use 544 and 50 wavelengths of light to measure reflection of the minerals. These reflective values can then be used to associate the minerals found on Mars with minerals common to Earth. These can then be used to find regions that contain minerals that are likely to contain, or have contained, water. Given that the hyperspectral imaging can contain up to a maximal 544 channels, viewing this data in a form that is familiar to humans is more challenging than it would be for a typical 3 channel image. These channels also generate a large amount of noise as the device has its imperfections and some of the channels simply do not contain useful information for every point at which it can be evaluated. Additionally displaying the output once a collection of waves have been identified to contain a particular mineral comes with its own breed of challenges. Additionally displaying this information in a format that can be easily shared is important to verify the results of the classification. The goals of this project are to provide an easy platform for viewing CRISM hyperspectral images on a desktop application that can filter out noise and overlay a classification map to aid visibility and verifiability of results. Removal of the noise will help to make the important aspects of the image more human visible. Overlaying the classification map provides easier verifiability to the results of the ensemble classifier that is used and also enables for comparison of results. Approach The programming language that will be selected for our implementation will be Python 3.7.2 assisted by the Anaconda Distribution to aid the construction of our application. The documentation and record of development and issues will be fleshed out through use of Github. Features of the software will first be documented as issues that will then the be developed on branches with a name tied to that issue. On completion of the feature a pull request will be issued and the issue will be up to revision before being added to the core project. Zachary will be designing the GUI for the application and implementing it in such a way that allows for easy extension in the future, broken into three separate tasks. This will be done using Tkinter, the standard Python library for GUIs. See Appendix 1 for design. Task A: Create a GUI that can display a 3-channel image with selectable channels.
Task B: Implement a classification overlay system that pulls from Travis and Bryce’s work to display an overlay map onto the 3-channel image. Task C: Design a file manager and extendable tabs in order to allow for more efficient work on multiple images. Travis and Bryce will be working on translating and implementing the mineral classifier and neutral pixel classifiers into Python, this will be broken into 6 tasks. Implementation of these tasks will be aided by the Anaconda Distribution package which includes a large variety of data mining and data analytics tools such as Numpy and Scipy. Task 1: Translate the model files to a format readable by Python. Task 2: Read in the image using the specified bands and remove invalid pixels. This will include displaying the 3 channel view of the image. Task 3: Implementing the two layer gmm function for use with both of the classifiers and assign each pixel a neutral pixel score using the classifier of the same name. Task 4: Calculate slog values, and use these values to ratio the pixels within a dynamically resizable window. Task 5: Apply median filtering. Task 6: Perform the mineral classification. Tasks 2, 3 and 6 have been delegated to Bryce and Tasks 1, 4, and 5 have been delegated to Travis. Expected Outcome, Testing, and Validation The expected outcome of this project is an application that is capable of performing the classification tasks assigned to us, neutral pixel classification and mineral classification, as well as display the output of this classification. The idealized end product will be one the facilitates easy navigation and provides a platform for the verification of the results against other similar studies. Testing will be performed utilizing the native Python library unittest. Unit tests will be written as the need arises throughout the project. They will be written using standard Class oriented design principles, one test per class that tests independant functionality of each class for which the class was written. Validation will be a moderately more subjective metric. Validation will come through two sources; meetings in which the application is demonstrated or discussed and its comparative performance against the mat lab code. Meetings throughout the semester are intended to address any issues as soon as they arise and to address any challenge to the current implementation. Meetings will also service to ensure that development conforms to the needs and desires that will be placed upon the software. Timeline Bryces expected Timeline: Task 2 is likely to take the largest amount of time followed by Task 3. Under this assumption it is anticipated out of the remaining 7 weeks the break down will be 3 weeks for Task 2, 2 weeks for Task 3 and 2 weeks for Task 6, each of these including time for testing and
integration. Integration will likely be the biggest challenge to tasks 2 and 6 whereas task 3 should have not yield any major concerns related to integration. Traviss expected Timeline: Task 4 is likely to be the task that will take the most amount of time out of these three tasks, so with that in mind two weeks will be dedicated to Task 1, three weeks will be dedicated to Task 4, and two weeks will be dedicated to Task 5. One of this biggest expected challenges will be that Task 4 is dependent on output from what is generated in Task 3, but the tasks are going to be developed in parallel. This will make testing of this step difficult during the early development, but with good communication between Bryce and Travis should be doable. Zachary’s expected Timeline: Task A needs to be the first completed task and is thankfully the simplest and will take 2 weeks at most. Task B requires integration from the mineral classifier and will likely be the most challenging, so 3 weeks will be given to it. Task C doesn’t have any prerequisites with regard to reliance on other tasks so it will be assigned 2 weeks and be done after Task A is complete and worked on until Task B can be initiated. After Task B is complete, what remains (if any) of Task C will be completed. The Groups expected Timeline: Week 1 Task 1 Task 2 Task A Week 2 — — — Week 3 Task 4 — Task C Week 4 — Task 3 — Week 5 — — Task B Week 6 Task 5 Task 6 — Week 7 — — — The first milestone meeting will take place March 8th.
Appendix 1: GUI Prototype Design