imageManager.getImage

Module Development
1

Hi all,

I'm dynamically importing images using something along the lines of:

ImageManager imgMgr = getMyContext().getImageManager();
ImageRecord i = imgMgr.getImage("icons/" + filename);
byte[] bytes = i.getBytes(ImageRecord.Data);

This works fine for svg, jpg but any time I try to get the width/height/description attributes of a PNG file it will fail with a null pointer.

Have I got a dodgy PNG file or is there a general issue with getImage and PNG's?

2

Can you provide a more complete code example that shows this aspect as well as the full stack trace of the error you get?

3

Sounds like you have a bad PNG but this can happen to any type of image. Ignition itself does not require you to have a description width or height (and it does no verification to width / height from what I can tell).

4

Thanks for the responses. I came to the same conclusion as jimender2 and found that just passing in 0's worked fine. So now I can see my programmatically copied images in the designer and also in data/modules/com.../icons

The problem I have now is that I always get a "Unable to parse icon library at path data/modules/com.inductiveautomation.perspective/icons/SAP logo.png" message when I restart the gateway. I'm sure it has to do with me just copying assets where I want them and leaving the AssetManager/IconManger to get on and do its thing.

I feel I should be trying to make use of AbstractAssetManager and setting cacheKeys or something but I just can't find any documentation about this.

5

So, once again we can scratch this one up to me being an idiot. It's all working perfectly now. The issue was that I had a maven dependency declared twice, each with a different version number! I was making changes in 1.1 but the resources were being pulled out of SNAPSHOT-1 which had a bunch of PNG files in the icons/ directory which were then being dropped into the gateway icons/ directory. I'm pretty sure the IconManager cache is not exactly thrilled about having PNG files in there rather than the SVG files it was expecting!

So, all is once again well with the world.