The purpose of this assignment is to gain experience working with Java I/O and exception handling.
Congratulations! MIMP has been a huge commercial success. Your next task is to add some additional functionality related to file I/O. Specifically, you will need to:
The first phase of this project is to design a file format that will allow you to save images to non-volatile storage. Your file format must be text-based, but beyond that, the layout of your files is entirely up to you. Part of your submission for this project will be a short document describing your file format. This document must include a small example along with an explanation. You should provide enough information for someone else to implement file I/O methods that could read and write your image files.
Don't be thrown off by the .mim extension. The files you will be saving and loading for this project are regular text files formatted to store image information. This is analogous to .java files: Java files are plain text documents where the .java extension tells us that we should interpret the contents as Java instructions.
In designing your file format you need to consider exactly what information needs to be stored to allow you to accurately reconstruct a particular Image object. As an example of this process, consider the Point class that we worked with earlier in the semester:
In the case of Point objects, only two pieces of information need to be stored: the x-coordinate and the y-coordinate of the point. Any of the formats below would work. They each contain all of the information necessary to create a new Point object that is identical to the Point object that was saved.
Format #1:Point x: 1.0 y: 2.0Format #2:
x: 1.0 y: 2.0Format #3:
1.0,2.0
Each of these alternatives has strengths and weaknesses. The first is particularly easy for a human to read and understand, but it "wastes" space on information that isn't strictly necessary for reconstructing the point. The final alternative uses less space, but may not be as clear to a human reader. Another issue to consider is ease of implementation. The file I/O code for reading the first alternative above will be relatively difficult to write because of the more complicated structure of the file.
Once you have decided on a strategy for storing images, you must update your Image class so that it conforms to the following UML diagram:
The last four methods are new. None of the existing methods will need to be modified.
Method Details:
saveImage(File file) throws FileNotFoundException
saveImage(String fileName) throws FileNotFoundException
These methods should write .mim data to the indicated file. Each method will
throw a FileNotFoundException
if the indicated file
cannot be opened for writing. These methods do not need to
check the provided file name to ensure that the .mim extension is
used. The functionality of these two methods is almost identical. Be
careful to avoid code duplication.
loadImage(File file) throws FileNotFoundException,
ImageFileFormatException
loadImage(String fileName) throws FileNotFoundException,
ImageFileFormatException
These methods attempt to build an Image object by
reading .mim file data from the provided file. An
ImageFileFormatException
must be thrown if the file does not
conform to your file format. Your code should throw an exception if
it encounters missing data, incorrect data, or extra data.
Note that ImageFileFormatException
is not a standard Java
exception type. You will need to create this class.
For the second part of this project you must make the necessary modifications
to MimpApp.java
so that we can read and write .mim files using the
graphical application. Files should automatically be saved in the
.mim format if they have the .mim file extension.
Here are the Java files necessary for running the MIMP application: (These were included in the .jar file for the previous PA.)
MimpApp.java
is fairly large, complicated, and
hard to read. (Most of the code in that file was automatically
generated by a GUI design tool.) Don't panic! The changes you
need to make are relatively minor. Don't worry if you don't
understand every line of code. Just do the necessary detective work
to figure out what needs to be modified.
The existing implementation of MimpApp.java
presents the
same error messages if there is any kind of error in reading or
writing files. You may stick to that design. You don't need to print
different error messages for missing or corrupted files.
Submission for this assignment is divided into two parts that should be completed in order.
In order to complete Part A you should first carefully read the project specification. Once you feel confident that you have a good grasp of the project requirements, log into Canvas and complete the Part A quiz. YOU MUST ANSWER ALL QUESTIONS CORRECTLY TO GET ANY CREDIT FOR THIS PART. You may take the quiz as many times as necessary.
For this part you must submit your updated Image.java
file along with ImageFileFormatException.java
, your
.mim documentation and your updated MimpApp.java
file.
The .mim documentation should be a plain text file named
"MIM_README.txt"
. All of the Java code submitted for Part B must
conform to the course style guide. You do not need to submit driver
code or unit tests.
You will receive at most 50% of the possible points for part B if your code fails any of the instructor unit tests.
Part A | 10% |
Part B Web-CAT Correctness | 50% |
Part B Web-CAT Checkstyle | 10% |
Part B Instructor Grading of GUI Functionality | 10% |
Part B Instructor grading based on style and code quality | 20% |
This assignment will include a penalty for excessive Web-CAT submissions. You are allowed unlimited attempts for part A. For Part B you are allowed ten submissions with no penalty. There will be a deduction of .5 for each additional submission beyond ten.
It would be unusual for a commercial image processing
application to rely on a text-based file format because
this approach uses more space than necessary. For example,
consider the amount of space required to store the
string "255"
to a text file. Each character
requires eight bits, for a total of 24. On the other hand,
the binary encoding of the integer 255
only
requires eight bits. This means that a text file storing
eight-bit integers (like our pixel color values) will be at
least three times as large as a binary file storing the same
data. In practice, the difference will be even larger
because the text version will require some way of separating
subsequent integers: "255,241,23". Such separators aren't
required in a binary file because each integer takes up
exactly the same amount of space.
If you want to go further with this project, develop a
.mimb binary image format for storing and loading images. You
are welcome to add additional methods to
your Image
class for working with your binary
formatted files.
You are not required to complete this part of the project. No extra credit will be awarded.