This is a discussion on Pattern suggestion for processing similar image types within the Software Patterns forums, part of the Testing category; Hello. Some of you may have knowledge of the PGM [1] family of image formats. As one of the activities ...
|
|||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Pattern suggestion for processing similar image types
Hello.
Some of you may have knowledge of the PGM [1] family of image formats. As one of the activities of the Pattern Recognition course that I am undertaking this semester, I had to write a simple tool which is capable of parsing PGM images and realize some kinds of operations with two given files. The tool is supposed to be able to handle at least two variants of the format: the /raw/ one and the /plain/ one. Both variants have the same header structure; the difference between them lies in the "magic number" used at the beginning of the file ('P2' for plain and 'P5' for raw) and the way the pixel information is stored. For the /raw/ format, pixels are stored as a sequence of 8-bit byte values; the /plain/ format, on the other hand, keeps pixel values as whitespace-separated ASCII decimal numbers. What I have so far is a PGM class which is able to parse and extract information from an input stream. The constructor of the class currently reads the magic number and the other header data from the input stream. Then, based on that magic number, it decides how the pixels should be treated (as binary or ASCII values). Although the tool is doing what it is supposed to do, I would like to experiment with some design improvements. What pattern or patterns could I employ in order to handle the above situation? Again, the different formats are recognized by the "magic number"; the rest of the header is processed identically for the formats; finally, the pixel data may be treated in two different ways, based on the "magic number". I would appreciate any ideas or suggestions. [1] http://netpbm.sourceforge.net/doc/pgm.html Thank you, -- Ney André de Mello Zunino |