loading image data with python HOM

[eestrada]

I am trying to load image data directly from disk into a python COP asset. So far I haven't found any way to get usable data. There is the hou.readFile() function, but this just interprets the binary data as a string making it a garbled, unusable mess. The other option I have thought of is to use hou.hscript() to run the "tex" hscript function, but this seems like it would be both very slow and error prone to wrap hscript code inside python code. Using hou.runVex() seems to have the same weaknesses as using hou.hscript(). I would ideally like to get the pixel data as an array of floats.

Does anyone have any ideas or suggestions? I feel like I am missing something super basic. Thanks in advance.

[symek]

There is the hou.readFile() function, but this just interprets the binary data as a string making it a garbled, unusable mess.

Have you read the Help page about writing COPs in Python? It is very extensive(!) and brings you a the examples of how to convert binary strings to an array of floats.

The other option I have thought of is to use hou.hscript() to run the "tex" hscript function, but this seems like it would be both very slow and error prone to wrap hscript code inside python code. Using hou.runVex() seems to have the same weaknesses as using hou.hscript(). I would ideally like to get the pixel data as an array of floats.

Neither hou.hscript() nor hou.runVex() can do this job. It's not a weakness, there are wrong tools for that.

[eestrada]

Have you read the Help page about writing COPs in Python? It is very extensive(!) and brings you a the examples of how to convert binary strings to an array of floats.

Neither hou.hscript() nor hou.runVex() can do this job. It's not a weakness, there are wrong tools for that.

SYmek, thank you for the advice. I have read the help page you are talking about. I thought that converting binary strings was just for numpy which is not included with Houdini, but it looks like it also works with the built-in array module, which I had missed in previous readings. I am trying to get it to work now, but having troubles. It keeps complaining about the array not being the right size when I use the binary string as input. It may be because of the number of components (RGBA instead of the expected RGB). However I think it is more likely that the hou.readFile() function doesn't do any conversion of files, it just reads in the literal binary data from disk. Thus image files would still have whatever wonky formatting and compression their format specifies.

You were absolutely right about the hou.hscript() function; I tried it and it was painfully slow (as I had guessed it would be). I haven't tried hou.runVex(), but I am not planning on pursuing that option given my hou.hscript() experience and your advice.

Another solution I am thinking of exploring is using the inlinecpp HOM module to use the HDK to read and convert the image files. However I would still prefer to keep this asset 100% python for the sake of simplicity and readability. Do you have more advice on passing the binary string properly to the planes of the COP asset or does anyone else have any ideas on how to read in a image file using purely HOM python?

Edited April 13, 2012 by eestrada

[edward]

I'm not sure why you would want to do this for a COP asset at all. Just use File nodes to load your images and then wire them as inputs of your custom node. Not only is this simpler, it is also more procedural.

[eestrada]

I'm not sure why you would want to do this for a COP asset at all. Just use File nodes to load your images and then wire them as inputs of your custom node. Not only is this simpler, it is also more procedural.

The node is for merging multiple images into an hdr. In order for it to work properly/automatically it needs exposure metadata like aperture and shutter speed. I figured it would be easier to grab that data if I was reading the files from disk myself. However, it may still work by having the user input the metadata themselves in some parameters and still get all the actual color data from file cops as inputs. That hadn't really crossed my mind since I was trying so hard to make it automatic; now I feel dumb for not thinking of that. I guess I just got really focused on the idea of it being self contained.

It still seams a bit odd to me that there isn't a way to read in image data via HOM. There is the HOM function hou.pixelColorInFileByUV(), but it isn't implemented yet. Well, loading the image data through file COPs should be faster anyway. I will hack away in that direction and let you all know what happens.

[3dbeing]

couldn't you just make a button that will read the necessary metadata of the indicated file and fill in a field? Extra step, but it's just a button.

[symek]

It still seams a bit odd to me that there isn't a way to read in image data via HOM.

This is by design, since developing classes which store native data would be doubling Houdini's nodes functionality. As far as I understand, the idea of HOM was to be able to manipulate native containers, operators, not duplicate in code, what is already possible in nodes, which makes sense considering endless possibilities of operators already implemented. Saying that, it seems SESI is filling gaps in scripting workflow:

Monday, April 9, 2012

Houdini 12.0.591: Added ability to create new hou.Geometry() objects (g = hou.Geometry()).

Also, strictly speaking you can load image data via Python using external library like PIL, OIIO, can't you?

[eestrada]

This is by design, since developing classes which store native data would be doubling Houdini's nodes functionality. As far as I understand, the idea of HOM was to be able to manipulate native containers, operators, not duplicate in code, what is already possible in nodes, which makes sense considering endless possibilities of operators already implemented. Saying that, it seems SESI is filling gaps in scripting workflow:

Also, strictly speaking you can load image data via Python using external library like PIL, OIIO, can't you?

@ 3dbeing: Good idea. That could keep the computation of the exposure automatic, but still use the speed of the built in file COP. I will first try to get the functionality of just merging HDRs and then move on to making convenient features like that.

@ SYmek: I see what you mean. Duplicating functionality within HOM is wasteful and slow. And yes, I could use an external library, but I wanted to keep the COP node self contained so that it is easier to distribute to a wider audience.