AndrewHazelden wrote:
Updated the script to have cross-platform Fusion 8.2.1 + Fusion 9.0.1 support. This revised version of the hos_SplitEXR script will not work in Fusion 7 anymore.

The script can now be installed as either a Fusion Comp script (Scripts:/Comp/) that is accessible using the main Fusion menubar's Script > hos_SplitEXR menu item, or as a Fusion tool script (Scripts:/tool) and accessed by right clicking on a Loader node in the flow area and then selecting the Script > hos_SplitEXR contextual menu item.

Improved the Lua script comments to make the program flow easier to understand for new pipeline TDs who need to customize this script in the future.

Improved the error handling and added more verbosity to the error messages.

Changed the Fusion preference writing path to use the user preference profile folder since the applications folder is usually write locked for non super-users.

Updated the "myLoader = Loader({Clip = exrFileName})" line to use the comp.Loader() prefix to avoid a tool script based error.

You do not have the required permissions to view the files attached to this post.

Last edited by AndrewHazelden on Wed Oct 04, 2017 2:35 am, edited 2 times in total.

ShadowMaker SdR wrote:Andrew, maybe it's a good idea to rename the file to reflect its compatibility?

Done. I renamed the revised script to "hos_SplitEXR_fu9.lua".

To be honest though I kind of suspect anyone still using Fusion 6.4 or 7 has locked their Windows XP - Windows 7 system in time and turned off all updates from the outside world. Those classic Fusion version using people are also the least likely to be hunting in a WSL "Any alternative to hos_SplitEXR?" thread.

I like the idea behind that sentiment but have you looked at the code in the script? (Original script edition if you want to be precise.)

I truly think you would not have used that last sentence if you did. Lol.

I went through and heavily annotated the script with comments for the parts I could decode and understand so future generations would have more idea what was going on inside.

The "simple" act of changing the Lua script filename on disk like you suggested actually modifies how the script works internally for example and will make the old preference files not be read anymore since a new filename is automatically generated. Here is my decoded and commented section from the updated script that explains how the SplitEXR preference file name is derived from the current Lua script name.

Everytime you rename the script you get a new preference file. I also added Console printing messages that indicate where the preference file is being read/written from in the update.

"To be honest though I kind of suspect anyone still using Fusion 6.4 or 7 has locked their Windows XP - Windows 7 system in time and turned off all updates from the outside world. Those classic Fusion version using people are also the least likely to be hunting in a WSL "Any alternative to hos_SplitEXR?" thread."

I respectfully beg to differ. I've been using 7.7.1 on win 10 machines (complete with Msoft's forced updates) for a year and a half on a project that's only now finishing, and uses exr files extensively. I tested fu8 early on and for all sorts of reasons (scripting issues, general instability, OpenCl crashes etc) didn't dare put it into production. The same certainly applied even more so to 9.0.0, which I assume is why BMD rushed to get 9.0.1 out.

Don't get me wrong, the port to multiplatform was an enormous amount of work (and a very good thing), to say nothing of all the added features in 9.0, so these issues are not at all unexected. And although I'm currently testing 9.0.1 (which already seems miles better than 9 or 9.0) I'm not yet ready to trust it on a real production with impatient clients, deadlines and the rest. So I suspect I'll have 7.7.1 on my system for some time still, I'm afraid, and I wouldn't be surprised to find I'm not alone.

JPDoc wrote:And although I'm currently testing 9.0.1 (which already seems miles better than 9 or 9.0) I'm not yet ready to trust it on a real production with impatient clients, deadlines and the rest. So I suspect I'll have 7.7.1 on my system for some time still, I'm afraid, and I wouldn't be surprised to find I'm not alone.

IMHO I see Fu 8/9 users who are happy(ish) and regularly use the new Fusion versions for production use "warts and all" as being the artists primarily running Fu on Linux/Mac who don't have any other version of Fusion they would want to use on their systems.

The legacy Fusion 6 or 7 on Windows users tend to want to see the same stability and reliability they always had in the earlier Fusion releases before they would trust/allow themselves to be pulled into the new present day versions.

So. Saying it again, but with the upmost respect, I don't think a classic hos_SplitEXR user on Fu 6 or 7 would be hunting for updates for their existing (and currently installed) Fusion scripts and 3rd party fuses/macros/tools/etc... if they are holding their systems together with bailing wire and actively avoiding newer Fu releases. Lol.

* * *

As an upside, Fu 7 vs Fu 8/9 use a different Fusion user prefs / scripts folder of either the Pubic Users Document folder vs a %appdata% location so the different Fusion Lua script versions don't clash on that front.

The MatteControl node input changes (especially when placed inside MacroOperator/GroupOperator nodes) and several other revisions in Fusion also make it harder to bring complex Fu 9 comp files back into Fu 7 without some dataloss so the different versions are acting more as islands now.

JPDoc, how are you able to use Fu 9 in your tests without having working (accelerated) OpenCL support that doesn't crash when you go to the OpenCL Prefs window? You've likely got one or multiple NVIDIA GPUs in your Win 10 PC. Mac users are pretty used to having little to no GPU based acceleration so they wouldn't feel the pain of this issue as badly.

I'm currently testing (when I get time) on win 10 del precison M6800 laptop with a QuadroK3100m using driver 382.16. I just checked and it doesn't crash on 9.0.1 when I open the OpenCL prefs, and open CL acceleration seems to work, at least on the defocus node, which is about as far as I've got. The next set of tests will be on a win 10 i7-6700K workstation with dual Quadro M4000s and we'll see how it goes.

I'm also a 7.7.1 user and use it extensively in a team production environment daily. Some of the scripts I rely on in 7.7.1 work flawlessly and not having experience in updating scripts, it's caused me to not jump on board FU8 or FU9 yet. With more discussion happening on both here and the blackmagic forums I'm hopeful I can make the switch to FU9 for production as it sounds like there's been a lot of updates including 3rd party scripts etc...

What's interesting to me in software forums, we usually only hear about the stuff that's broken, so when I'm going through the forums and see stuff isn't working or bugs are found in the latest versions of FU, I shy away from them, because everything is still working well in 7.7.1.

But, Andrew with comments like your's it makes me a little less hesitant to move into FU9.