@trixie I wanted to embed some small images in a little program I was working on and had the same problem. I couldn't find an example that works so I gave up. However, your request set me off on another search and this time I may have found the solution. There is an example on the ADCD_2.1 developer CD that might do the trick. It uses DTST_MEMORY like thomas suggested. It opens an image file, copies it into memory and then displays it from memory. I was surprised that DTST_MEMORY works on an undecoded image file in memory but that seems to be the case. I tested the OS3 binary and it worked with a small IFF file. It displayed a PNG file but the alpha channel didn't work.Take a look at the directory ADCD_2.1/NDK/NDK_3.5/Examples/DataTypes/Memory on the dev CD. It seems to me that if the example can load the file into memory and display it then you should be able to load it into memory from an embeded array in your program. If you succeed, please share :-)

@trixie I changed the example to use proto/ includes instead of clib/, changed the FileInfoBlock (fib) to use AllocDiskObject, removed the extern library declarations, removed the amigaguide includes, added "PDTA_DestMode,PMODE_V43," & "PDTA_Remap,TRUE," to the NewDTObject function call and compiled the example for OS4 using -D__USE_INLINE__. It loads 32bit IFF files or PNG files and displays them with proper alpha channel blending :-)

@thomas The example did in fact have the filename as the first argument to NewDTObject but when I changed the name argument to NULL the example still works. Whether it works by copying the file from embedded data still remains to be seen. I'll try that as soon as I can. EDIT: I converted an image file to C source with BinToC, commented out the filereading code and simply inserted the embedded array address in NewDTObject (DTA_SourceAddress, &TESTDT_ARRAY). It works! It's probably a bad idea to pass the address of data embedded in a program but it was just for a quick test and the array should probably be copied to allocated memory.

@Hypex

A struct Image has no palette specified so it's a but hard to remap pen colours. But, where does PPaint save the palette? The Image palette would depend on the screen it is on and the Image settings determine what bitplanes and thus what pens are written into.

There are several programs at Aminet that will (ifftoC, iff2c, image2c etc.) produce palette and pen tables along with the image but that still leaves you with the problem of remapping to get the right colors on the target screen and that is way more complicated than I would want.

Are you blitting onto an RTG or classic screen? For RTG a bitplane based Image is no so efficient. Apart from datatypes I don't know how one would go about displaying a binary image. We don't seem to have a way of dealing with images otherwise.

There is penmap class which will accept chunky image data and pens or palette. There are several programs (mchunky) at Aminet that will convert an image to a C file containing chunky data & palette needed for penmap class. The penmap example in SDK:Examples/ReAction/os4examples/ uses embedded chunky data to display an image. However, a 956 byte iff file turns into 15,640 of bytes of chunky data in a C file so the datatype method of embedding the original iff file and loading the image from that is a lot more effecient as far as program size is concerned. The only potential problem with that is the 8bit CLUT screen issue reported in the "Strange DataType problem.." topic. Thomas states that setting PDTA_DestMode to PMODE_V42 is needed in that case which I suppose means that you would need to check the screen depth before you display the image with DataTypes. I've haven't found any programs that will convert a bitmap to a C file that can be loaded with bitmap class but it should be possible. I suspect it will suffer the same program size bloat that using penmap class produces.

@salass00 If by "raw image data" you mean the array data that will be embedded in the program; the embedded image data for the datatatype method of setting DTA_SourceType to DTST_MEMORY can be an embedded PNG file or ILBM bitplane file. I did some testing and bzip2 makes a PNG file larger in some cases.There might be some size advantage to compressing the chunky image data that would be used for the penmap class method of displaying an image but why bother when you can simply use data that is already in a compressed format with the datatype method?? Even if I could figure out how to save a bitmap for embedding in a C language file for use with bitmap class, the same holds true.

@Hypex

There are actually some pen functions I remember for obtaining or determining the best pen colour for an RGB value. For true colour it would be exact. But then of course you have your palette and would still need to remap that data to the screen.

Unless you're writing a graphics program, doing it that way would a fairly large distraction from the functional goal of the the program.

That's interesting as the IFF compression isn't considered the best and could lose out by being bitmap based.

Yes. The original IFF ILBM compression was not very effective and in the case of small images can be counterproductive. If you create a small brush in PPaint (less that 256x256) with an 8 color palette, saving it as a compressed ILBM will yield a larger file than if you save it uncompressed. However, if you save an IFF ILBM with few colors it can be smaller than a compressed RGB image because it only needs to contain the active bitplanes and not the bitplanes that are all zeros. For example, I saved a document scan as a 2 color (single bitplane) ILBM that has a filesize of 97526 bytes. Saving as an RGB PNG yields a filesize of 81179 bytes which is not that different from the ILBM file.

That's a bit older than I remember. I've heard of a PMODE_V43 being needed but not an earlier one.

I'm just quoting someone else's suggestion but I assume it means that you need to use the old remapping method for 8 bit screens.

BTW do I need to "DisposeDTObject()"?
Or does "DisposeObject( OBJ(OID_MAINWIN) );" dispose the datatype object too.