PA #4: MIMP I/O

Objectives

The purpose of this assignment is to gain experience working with Java I/O and exception handling.

Introduction

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:

.mim Files

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 following Point class:

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.0
Format #2:
x: 1.0
y: 2.0
Format #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.

File I/O

Once you have decided on a strategy for storing images, you must implement the MimpFileUtils class so that it conforms to the following UML diagram:

Method Details:

GUI Modifications

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.

Submitting/Grading

Submission for this assignment is divided into two parts that should be completed in order.

Part A: Readiness Quiz

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.

Part B: File Format, File I/O and GUI

For this part you must submit your MimpFileUtils.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.

Grading

Part A 10%
Part B Autolab Correctness 50%
Part B Instructor Grading of GUI Functionality 20%
Part B Instructor grading based on style and code quality 20%

Submission penalties

This assignment will include a penalty for excessive Autolab submissions.

Going Further: Binary File Format

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 MimpFileUtils 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.

Going Even Further: Lossy Compression

File formats like JPEG save even more space by taking advantage of human perceptual limitations. The digital image data captured by a camera's sensor contains fine details that are imperceptible to the human eye. Lossy file formats save space by discarding some of that detail.

Designing and implementing a high-quality lossy image format is well beyond the scope of this course. However, it would be relatively straightforward to experiment with a lossy version of Run-length Encoding. This would involve representing runs of similar pixels by storing the first pixel along with a counter indicating how many times that pixel should be reproduced when the image is loaded.

Again, you are not required to complete this part of the project.