Main Page | Namespace List | Class Hierarchy | Alphabetical List | Class List | File List | Namespace Members | Class Members | File Members | Related Pages

# Modules/ColorTableMod/ColorTable32KMod.cpp

Go to the documentation of this file.

    00001 /**
    00002 * @file ColorTable32KMod.cpp
    00003 * Implementation of class ColorTable32KMod.
    00004 *
    00005 * @author <A href=mailto:walter.nistico@uni-dortmund.de>Walter Nistico</A>
    00006 */
    00007
    00008 #include "ColorTable32KMod.h"
    00009 #include "Tools/Location.h"
    00010
    00011 /*
    00012 I don't like this.
    00013 Directly copying an object to a memory buffer is a C-style low level way of instantiating it,
    00014 beside, the initialization of the memory buffer looks quite ugly because of the test operators
    00015 to determine the size of the biggest colortable object, and it gets worser and worser as new
    00016 colortables are implemented.
    00017 I have a more elegant solution which gives access to colortables to the image processors
    00018 through a colortable pointer: it works, but it needed a thorough rewriting of the image processor
    00019 interface, and it has a potential for problems with image processors designed to use a
    00020 single color table (ColorTable64) such as GridImageProcessor2.
    00021 If you want to support this second approach, please write me an e-mail.
    00022 */
    00023 void ColorTable32KMod::setup()
    00024 {
    00025   ColorTable64* colorTable64 = new ColorTable64();
    00026   InBinaryFile stream(getLocation().getModelFilename("coltable.c32"));
    00027   colorTable64->setFormat(ColorTable64::CT32K);
    00028   if (stream.exists())
    00029   {
    00030     stream >> *colorTable64;
    00031   }
    00032   memcpy(colorTable, colorTable64, sizeof(ColorTable64));
    00033   delete colorTable64;
    00034 }