Is this possible? When i’m working with this extension ‘.cube’ in gimp [gmic/film emulation/user-defined] i need to wait and wait, only to see preview of that one preset.
Do you mean convert .cube to a HaldCLUT PNG?
In GMIC, have a look a Colors > Customize CLUT
thanks for the replay!
yes, that would be cool if i can find solution how to convert .cube=haldclut .png i suppose the process of previewing would be faster?
customize clut in gmic is only for making your own lut [from scratch], right?
Hello @nkl,
In the final release of version 2.0.0 done yesterday, the command that reads cube files should be a bit faster to run. I suggest you upgrade/reinstall the latest version of your plug-in, and give another try.
What is the resolution of your .cube files ?
hi David!
yes, thanks for the info about new version of gmic! i installed and now it seems it’s not working in my case. i have jessie debian, linux. maybe because i have an older version of gimp [2.8.14], i don;t know. the process of previewing .cube it’s not working now.
what os you have?
p.s.
resolution of .cube file, i really don’t know. one .cube file has 5 mb.
@nkl, that is interesting, thank you !
The .cube loading function has been recoded from scratch, so there might be some regressions.
Could you put one of your non-working your .cube file somewhere ? I’ll try to fix this ASAP !
thanks David!
here’s the files [two] btw, these files are not mine, i downloaded from net as free from Oleg Sharonov
Thanks a lot @nkl, I think I’ve found the bug, and now your .cube files works in the GTK-based plug-in.
Unfortunately, it seems there is still a problem with the Qt-version of the plug-in, I’ll investigate that soon.
Thanks again !
Now I know why this doesn’t work on the Qt-based interface. Used a too much aggressive optimization flag with the compiler 
So, I’ve started the 2.0.1 bump, and I’m currently building new binary packages. Should be ready in one hour or so.
1 Like
hi David!
now in the 2.0.1_pre works so smoothly! [yeiii :D] no waiting at all! 
thank you so much!
Compiled latest 2.0.1 prerelease and now applying *.cube take infinity time.
Check the compilation didn’t use the -Ofast optimization flag. This was the cause of the problem in the Qt-based interface, as -Ofast enables -ffast-math which does not manage NaN numbers correctly (leading to infinite loops in the .cube loading command).
I’ve tested this filter with 2.0.1 with the CLUTs from @nkl, and it was working as expected.
I’m using gtk interface. Is it important to not use -Ofast with gtk interface?
Yes, you should not use -Ofast for any of the G’MIC interface. This avoids the managing of NaN number in the G’MIC core library (used by all these interfaces), and it makes this particular filter loop infinitely.
I suggest you use -O3 then, which is just fine.
How about adding something like
#ifdef __GNUC__
#if defined(__FAST_MATH__)
#error Using the -ffast-math CFLAG is known to lead to problems. Disable it to compile.
#endif
#endif
1 Like
Thanks! Now it works great and much much faster than 1.7 version.
1 Like
Hi @David_Tschumperle, I just compiled the gimp plugin (latest code: 2.0.3_pre#170728). I tried to apply a simple .cube CLUT, but I get the “Preview warning: Specified HaldCLUT filename not found” error. This filter is still not completely working in the Qt plugin?
Could you send me the. Cube file, so I can test? Thanks!