Eiffel Image Embedder Tool

by Larry Liu (modified: 2007 Oct 10)

From SVN revision#70058, we have a tool to embed images in executables (e.g. exe for Windows). The name of the tool is Image Eiffel Code' which stays in $EIFFEL_SRC/tools/image_eiffel_code’.

Snapshot of the tool:


  • Image embed

The basic feature of the tools is embedding images in executables.

This is useful for libraries which need comes with a set of icons. All client programmers of the libraries don't have to providing a set of images since they are embedded already.

Of course, executables can use this tool too. End users of the executables will not care about the working directory. The executable folder will look clearer and professional since there are fewer files.

Smart Docking library use this tool to embed icons currently.

  • Multi-platform

Multi-platform embed image solution. On different platforms, the tool has almost the same performance.

I have tested it on Windows XP 32/64bits and Ubuntu. Manu have tested it on SPARK Solaris.


  • loading speed

The loading speed is a little bit faster than loading a png file directly (by GDI+ on Windows, by GTK on Linux). If the time of loading a png file directly is 100, the time of loading an embedded icon is about 80.

  • final machine code size

Because the tool doesn’t compress target image contents, so the image size of generated in executables is larger than original png file. But the embedded image size is only little bigger than a bmp size. It's about 1.3 times as large as original bmp's size.

How it works

The basic idea of the tool is generate an Eiffel class file which can represent original image file (maybe png, bmp, jpg or any other image format files.)

If you have seen generated image Eiffel class file, you will find:

  • make

This is the creation method of generated image Eiffel class. It can initialize an EV_PIXEL_BUFFER instance, the fill the memory contents of EV_PIXEL_BUFFER.

  • c_color_x

`c_colors_x’ (x is an integer) is the features which can fill a memory pointer with data. The data come from original image file.

You may ask why we can’t use only one c_color_x’ feature to store whole image data instead of separate c_color_x’ features. The answer is in following `Future’ section.

You may also noticed that the C pre processor in the external feature. The reason is the different image data order between Windows and GTK. In Windows GDI+, the color bit order is Alpha, Red, Green, Blue’. But in Linux GTK, the order is Red, Green, Blue, Alpha’.

The last trick in c externals is why using char[] to store image data, but not unsigned int [] or others. The reason is compiled executables size. For gcc on Linux, it make no differences between char[] and int[]. But on Windows with Microsoft vc compiler, the compiled int[] array machine code size is about 3 times bigger than the compiled machine code size of char[] array. Because Microsoft vc compiler, generated machine code don’t store int[] in a continuous sequence. Fortunately, the vc compiler store char[] in a continuous sequence which can save a lot of generated executables size.

  • `build_colors’

This feature invokes all the `c_color_x’ features. So it can fill whole image data into a memory pointer in single call.

  • fill_memory

This feature can find the memory access pointer of our EV_PIXEL_BUFFER, then it invoke `build_colors’ to fill the image contents.


Because the limitation of Eiffel manifest string size is about 32kb. The Eiffel c external features string is a kind of Eiffel manifest string which can’t larger than 32kb. So the tool generated a lot of external features in the generated image Eiffel class. If the limitations removed in the future, the performance (loading speed and icons size) of the tool will improve.

  • Tao Feng (9 years ago 9/10/2007)

    A nice tool!

    If the external manifest string length limitation were removed, the performance would dramatically increase. <br> And this could be reused by resource library someday.

    • Larry Liu (9 years ago 9/10/2007)

      The father of the tool is Ted. I just improved it. ;)

  • Peter Gummer (9 years ago 9/10/2007)

    EiffelBuild Integration

    It will be great not having to deploy all of those image files any more.

    But "Image Eiffel Code" is a funny name. How about something like "EiffelBuild Image Embedder"? Also, wasn't there a decision during the development of EiffelStudio 6.0 that the executable name for tools like this should start with "es"? How about "esimage" instead of "image_eiffel_code"?

    I suggested the name "EiffelBuild Image Embedder" because, in order to give us a smoothly integrated development experience, these image classes should be generated by EiffelBuild. Not everyone who might want this automated image generation uses EiffelBuild, however, so I agree that there is a need for a separate tool; but those of us who use EiffelBuild should be able to choose the images we want embedded from within EiffelBuild, and then EiffelBuild should just generate all of the classes.

    • Paul Bates (9 years ago 9/10/2007)

      Tool and executable name

      Larry, Ted, I have to agree with Peter. The current name isn't to clear.

      I've not examined the tool yet but the executable name should be short because it's a command-line tool. No one wants to type "image_eiffel_code". Generally underscores in executables are a no-no. For instance, the tools we have now:

      Eiffel Environment Command Spawn Utility => espawn
      EiffelVision2 Pixmap Matrix Code Generator => emcgen
      Eiffel Assembly Metadata Consumer => emdc
      Registry File to WiX Conversion Tool => reg2wix
      Eiffel Class Visitor Generator => vfact

      • Larry Liu (9 years ago 10/10/2007)

        Name Changed

        Hi, Peter, Paul,

        In revision#70545, we changed the tool name to Eiffel Image Embedder'. Target executable's name changed to eimgemb'.

        We don't have a decision that all executables' name should start with `es' yet. But we have naming convertion.

        For integration it to Eiffel Build, that's a good idea. But we don't have plan to do it for 6.1, we will do it later.

        Please let me know if you have comments or ideas.