After @kevtris posted the image of the font hidden in the image file, I thought it might be fun to poke around in there some more and see what could be seen.  I started by mapping out the following data areas (defined as "long" stretches of bytes other than 0xFF):

0x000000-0x000003: FF FF FF FF (4 bytes)
0x000004-0x029503: FPGA boot bitstream (169216 bytes)
0x030002-0x03D407: Something (54278 bytes)
0x040000-0x0400BB: Something (188 bytes)
0x09006C-0x0A3513: Something (79016 bytes)
0x0B0000-0x0B004B: Something (76 bytes)
0x0D6AFC-0x113513: Something (248344 bytes)
0x120000-0x1200D7: Something (216 bytes)
0x1400B8-0x141B05: Something (6734 bytes)
0x142B00-0x144605: Something (6918 bytes)
0x145600-0x147105: Something (6918 bytes)
0x150000-0x1500A7: Something (168 bytes)

There are three large blocks of data, and in each area can be found a copy of the font that @kevtris documented.  Presumably these are firmware images.

The font was found with bit spatial analysis (a term I'm using because I don't know the proper term for this) using yy-chr.  That got me thinking, what else might we figure out by looking at the dumped image visually?  So I mangled the data a bit and came out with the following grayscale representation:

Interesting.  If we know the first band at the top is the FPGA's boot bitstream... then the band in the middle sure looks like another one - but upside down.  The data seems to back this up - starting at 0xFFFFF and continuing backward to 0xD6AFC, there seems to be another 169220 bytes of bitstream there.  I ran a diff between the two bitstreams, and though they look similar, about half of the bytes are different - and since most of the bitstream is zeros, that means there are a whole lot of differences.  But they are both undoubtedly the same type of data:

With that chunk removed from the 248K of continuous data noted above, we end up with 79124 bytes - much closer in size to the other two similar-looking sections.  Given this, the presence of the font in all three places, as well as a set of strings in all three, it seems that the flash contains two bitstreams, three firmwares, and some small chunks of other data interspersed here and there.  Neat!

[Edit] Addendum.  The reversed bitstream is a documented feature of Spartan-3E.  It is part of its MultiBoot function.  On first powerup, the FPGA loads a bitstream starting either at the bottom of its address range and reading up, or from the top of its address range and reading down, depending on the configuration of the bitstream header.  Then once this is loaded, by toggling the FPGA's MultiBoot Trigger signal, the FPGA is instructed to reconfigure itself from the opposite end of the memory in reverse order.  Except as you see here, the second image is at 0x0FFFFF, which is not the end of the flash address space, so the programmer seems to have done something interesting with the memory architecture.  It is possible that the flash configurator (iMPACT or similar) was configured for a 1M flash, and the programmer appended additional data after the end of the MultiBoot bitstream, because I can't otherwise figure out how to get iMPACT to override the start address for the second image...

The dual bitstream function is often used as a safety feature for field-upgradeable systems.  One of the two is protected, and the other is allowed to be written by user software.  If the upgrade goes poorly, there is always a known-good bitstream to bring up the FPGA so that it can be attempted again, and you don't have to go find the JTAG cable.  Another neat feature that Barco may have taken advantage of.