OpenEXR import Spark

[Anonymous]

loops wrote:

Oh no 🙁 I checked the older docs and it seems anything before Flame 9/Inferno 6/Smoke 6.5 doesn’t let you choose an image sequence in a file browser from a Spark 🙁 So the version above is only going to work on Flint/Flame 9, Inferno 6, Smoke/Fire 6.5 and up 🙁

I might be able to make one which works for older versions by making it read all files from a folder as a sequence, if people want… thanks for the bug report 🙂

Ok, that could work. Could you add a option to repeat the 1 frame? Say we have a one frame openexr file, ie a bg plate. and loop that for x frames?

Thanks for looking into this…

C.

[bnw]

Tom, you have the same problem as Cerebros, the sequence file browser only works in Inferno 6 and up. I’ll try and do a cruder version that will work for you too. Thanks for testing 🙂

Cerebros, the easiest way would be if I fix it up so that to load a still, you put it in a directory all on its own, would that work for you? As it is a still is output on all frames anyway.

[kingcoon]

this would be so cool. for versions before multires (like the old and trusty inferno 4.7.4) it would be nice to include a crop/fit/letterbox selection before loading the sequence – if it is not too complicated to include in the spark code.

and again many thanks for your work and especially for sharing it with all of us.
Tom

loops wrote:

Tom, you have the same problem as Cerebros, the sequence file browser only works in Inferno 6 and up. I’ll try and do a cruder version that will work for you too.

[bnw]

I did think about resizing while I was writing it – it’s especially annoying when an OpenEXR file is not a multiple of 8 pixels wide, or whatever Flame’s restriction on that is, because you then can’t load them at all 🙂 Cropping should be doable, resizing opens the whole can of filtering and interpolation worms… I’ll aim for a version that actually works for people first 😉

[Anonymous]

loops wrote:

Tom, you have the same problem as Cerebros, the sequence file browser only works in Inferno 6 and up. I’ll try and do a cruder version that will work for you too. Thanks for testing 🙂

Cerebros, the easiest way would be if I fix it up so that to load a still, you put it in a directory all on its own, would that work for you? As it is a still is output on all frames anyway.

It’d be a little bit of a cludge, but I suppose it could work out. Anything you could do would be amazing. The OpenEXR sequences will still work right? They just need to be in their own directory? Oh, and no multiple spark outputs in the 9.x APi either eh?

thanks

C.

[bnw]

Okey dokes, I’ve uploaded a version which doesn’t use the new sequence file browser so people with older Flames should have more luck 🙂 It now loads all the images in a directory as a sequence, but this time it has start and end controls.

http://lewissaunders.com/sparkOpenEXR/sparkOpenEXR_Irix.tar.gz
http://lewissaunders.com/sparkOpenEXR/sparkOpenEXR_Linux.tar.gz

Noticed one thing on my system… if you load an image into the Spark in Batch, then change the Spark’s output resolution, Flame crashes when you re-enter the Spark. And it seems to crash in Flame rather than the Spark, yet doing the same tthing is fine on the reels.

On the upside it works really nicely with clip history – if you have an imported clip, just hit the H and you’re taken back into the Spark with all the setttings intact, and parked on the right frame, even 🙂

So, better luck this time 🙂

[bnw]

Cerebros wrote:

Oh, and no multiple spark outputs in the 9.x APi either eh?

No, annoying, that. The whole API is sorta showing its age. I wonder if Flame will ever support OpenFX, Discreet are on the supporters list. It doesn’t look to support multiple outputs either though.

‘Nother point… if you load a Z channel and it appears white, don’t worry, you just need to turn the exposure and gamma way down. Gah, I should write a manual but right now I’m off to play in the snow.

[kingcoon]

great, it works in inferno 4.7.4

you have to resize it to your current project image resolution but then everything works fine.

Thanks,
Tom

[Anonymous]

It workx, great. Now for some feedback,

As for the multiple outputs, you can cycle various openexr channels into the R,G and B channels and then split those out later with a CC or Separate node in batch. See it as a poor mans multinode out.

There is no way to see the resolution of a openEXR file until you’ve loaded it into the spark? Maybe a dialog showing the res of the file would be a welcome addition. This way we can see the resolution that we need to change the spark output res too before touching any of the buttons (and crashing ffi).

There are some print statements in the shell, I’ve seen that when you have the spark output these its sometimes a real performance killer.

Forget Resizing in the actual spark, the hassle with interpolation and so on is just not what the focus should be for the spark at this point (imho)

Is the spark multithread aware? I wondered since reading the files is largely a file IO thing and are those threads even Mthread capable…

Again, a great release Loops, thanks for that. You going to NAB? If so drinks are on me…

C.

[bnw]

Cerebros wrote:

There is no way to see the resolution of a openEXR file until you’ve loaded it into the spark? Maybe a dialog showing the res of the file would be a welcome addition. This way we can see the resolution that we need to change the spark output res too before touching any of the buttons (and crashing ffi).

You’re right, it’s annoying, but I’m not sure what else I could do… when you’re on the desktop it’s no problem, you can just load an image, it will complain and tell you what size it is, you can back out to the desktop, change the size and go again, but if you do this in Batch in crashes. Not really much else I could do, I guess in Batch you just have to delete the Spark node and re-add it, that should be fine.

Quote:

There are some print statements in the shell, I’ve seen that when you have the spark output these its sometimes a real performance killer.

Yeah, I turned them back on, it might help diagnose any problems people have. There’s only a couple for each frame so there’s no speed problem, but you’re right, at one point I had it printing on every pixel and things went right downhill 🙂

Quote:

Is the spark multithread aware? I wondered since reading the files is largely a file IO thing and are those threads even Mthread capable…

It’s not threaded. The slowest part is reading the pixels out of the file, and this can’t be threaded in any way, the OpenEXR library doesn’t like that at all. The other part, converting from float space to Flame’s buffers, could be threaded but that doesn’t really take much time. Overall it runs at about the same speed as the ILM exrdisplay app, loading files is slightly quicker but changing exposure slightly slower since mine has adjustable gamma and exposure per channel.

Quote:

Again, a great release Loops, thanks for that. You going to NAB? If so drinks are on me…

I’d love to, but sadly it’s on the other side of the world from me and all 😉 Thanks for the feedback.

[Kenzo]

loops wrote:

I wonder if Flame will ever support OpenFX, Discreet are on the supporters list.

Don’t know if flame ever will, but Toxik uses OpenFX for it’s plugin API. That’s probably why discreet is listed as a contributor.

[Tony]

i think the amount of customer and fan email you must be getting right now
makes the people at the foundry jealous.
this is highly appreciated and very, very, very cool !

works exactly like it should and will safe me another trip to a linux box.

wolf

[prajjwal]

Very good job.

Including the source code is a nice touch.

I love it!

— Xavier

[Anonymous]

Hi Seems ILM has updated the source for openext to 1.3.2. This update has amongst its list of features, support for multithreaded file IO!!! Great for these highres multi-file/spark openexr comps!!!

Any chance of a update?

Here’s the latest source…

http://download.savannah.nongnu.org/releases/openexr/openexr-1.3.2.tar.gz

Thanks

C.

[Kjell]

way cool!

thanks so much for all that hard work! (now, could you just get to work on rewriting IFF for full floating-point workflow?)

could you please post the source or a link to it so that we can compile for the Opteron & 64bit linux?

if we are sucessful i’ll send the spark back to you so you can include it for download

thanks again

k

[Author]

Posts