With hard-commiting I could not find the way of just telling Flame to do the hard-import from python, so it is a bit of a work-around. Precisely it will go through this steps:
Can you see some of this additional steps happening? It’ll be useful to try to understand what step is failing in this case
It only gets as far as soft-importing the clip and no further unfortunately.
printenv in a shell returns: FLAMETWML_HARDCOMMIT=True so it looks like the variable is set correctly.
EDIT: It works as expected. I had to log-in and out and removed anything related the config and all good now. Thanks again for this!
This is an interesting thread, and am seeing if this ML timewaro can help a slowdown that client needs on some water footage… ie fast moving caustics… always a pain to slow down.
I can start a new thread but is anyone aware of a good uprezzing training for sharpening footage? I have some bird footage that is at 1080 but we need it a bit sharper as its getting scaled up for framing purposes? Any experience with doing the ol ‘enhance’, … ‘enhance’ …trick?
Theo
If you have a nuke available to you. TVI Scale is pretty amazing.
We ran it through ML timewarp. its brilliant, it made fast moving water… think miami blue water. 50% speed. fantastic result. Well done! much props!! it didnt feel warpy and elastic. its great!
Hi @talosh - Just wanted to commend you on this - amazing! I have it working on my MBP (Mojave Flame2020.3.1), but struggling with an error on my iMacPro (Catalina Flame2020.3.1). Any help would be much appreciated to hopefully benefit from a faster processor! Just a report that a nightmare scenario for timewarps—speed ups and downs on 800asa 3k Super16—worked pretty much amazing. None of the tearing or warping.
My mind is blown, again.
Hi Angus,
From that logs it looks like Catalina is someow blocking miniconda3 from starting up. It might be connected to default security settings. miniconda3 is the base layer, something like “minicontainer” that makes the whole thing to run in fairly recent python 3.8 environment without disturbing default system python.
i would suggest to try to install it in different folder that doesn’t belong to /Users tree first. If it doesn’t work there’s an option to install miniconda3 from more MacOS friendly graphics installer and manually set up dependency libraries
Am I wrong in thinking that /opt is the acceptable environment?
I can’t quite remember but I think this was partly why autodesk moved their software to /opt/Autodesk - to be good ‘nix citizens or something.
It is currently possible to coose any fs location including /opt to unpack and install components needed. The reason it currently have user’s home folder as default it to be able to keep it completely in user space and avoid administrative privileges
Thanks for the explanation - there’s always been a problem with flame, admin and user privileges.
It’s not an easy solve.
Hi guys, those on Mac with discreet GPU, would you mind to test Timewarp based on different beckend that would alow to use GPU on Mac? It does not seem to be useful with integrated Intel graphics and I don’t have much access to other macs with AMD cards at the moment. It is a standalone app and the thing is to check if it worth to use it as additional beckend with flameTimewarpML for Mac
This works a treat on an iMac Pro with Radeon Pro Vega 64X 16 GB. 40 to 79 frames of 4480 × 3096 in 2 minutes without complaint.
It’s a shame Catalina is making my “python life” miserable though. Something I need to fix. 
Hi,
did some testing with an Imac Pro with Radeon Pro Vega 64X 16 GB and eGPU Radeon PRO WX 9100 and it seems very promessing.
The sequence i use is a 224x1548 200 frames long with a TW set to 50%.
All the tests are done on the local hard drive.
The two gpus have pretty much the same performance (around 240 sec).
I was unable to try using both gpu at the same time, but just select which one to use.
I’ll try in a future a script to force the use of both.
CPU performance was a disaster and took over 1300 sec to do the same task.(probably has different setting in the use of cpu compared to the one within flame application)
From within Flame application with those settings and model v2.3
Free RAM: 97.2 Gb available - Image size: 2224 x 1548
Peak memory usage estimation: 6.9 Gb per CPU thread
Limiting therads to 14 CPU worker threads (of 36 available) to prevent RAM from overflow
things are a not so easy to test. It seems that for short sequence (100-200 frames) is similar or even a bit faster then gpu render from the “stand alone” app… but after that limit of frame range, it start to really slow down. For long shots it takes really a long time and the more the time passes, the slower it goes.
Maybe with some tweaking in the use of ram and cpu could work better.
In conclusion…
The advantage i see in the stand alone application with the new beckend is that i can use a egpu just for the TW task and keep working in flame without using cpu or internal gpu, and that could be useful for long sequence.
Even with one GPU, it seems to have a more predictable rendering speed.
For sequence (commercial shot for example), that usually are not so long, i don’t see that much of a difference in performance.
I’ll keep testing to see if gpu are really more constant with the results compared to cpu.
Hope this info help,
Ciao
After many uses I hit my first issue… Processing bails immediately and reports:
Received 1 clip to process, press Ctrl+C to cancel
Initializing TimewarpML from Flame setup…
“invalid literal for int() with base 10: ‘1.5’ in <class ‘ValueError’>”
[‘Traceback (most recent call last):\n’,
’ File ’
'"/opt/Autodesk/flame_2021.1/flameTimewarpML/bundle/inference_flame_tw.py", ’
‘line 520, in \n’
’ frame_value_map = bake_flame_tw_setup(args.setup, args.record_in, ’
‘args.record_out)\n’,
’ File ’
'"/opt/Autodesk/flame_2021.1/flameTimewarpML/bundle/inference_flame_tw.py", ’
‘line 327, in bake_flame_tw_setup\n’
" tw_timing[int(index)] = {‘frame’: int(frame), ‘value’: float(value)}\n",
“ValueError: invalid literal for int() with base 10: ‘1.5’\n”]
Traceback (most recent call last):
File “/opt/Autodesk/flame_2021.1/flameTimewarpML/bundle/inference_flame_tw.py”, line 520, in
frame_value_map = bake_flame_tw_setup(args.setup, args.record_in, args.record_out)
File “/opt/Autodesk/flame_2021.1/flameTimewarpML/bundle/inference_flame_tw.py”, line 327, in bake_flame_tw_setup
tw_timing[int(index)] = {‘frame’: int(frame), ‘value’: float(value)}
ValueError: invalid literal for int() with base 10: ‘1.5’
…any ideas?
Hi Christofer, would you be able to send an archive with your clip and tw setup? Could be just dummy or noise of the same length and res if there’s a prob with the actual footage to be sent over.
The module that does timewarps from flame uses the Ruby code from Julik Tarkhanov to parse flame animation channels, and from the log it looks that it fails on parsing back the result (expecting frame to be round integer but given 1.5 instead).
I’d need to move this pars into python code somehow anyway so this might be a good cause to start )
Indeed it was a janky timewarp with non int keyframes and a quick simplify solved it. Thanks AAF. I’ll put it up on a link shortly @talosh so you can have a look. Thanks so much for all of your work and support with this.
Just recently installed CentOS 7.6 on a z8. Any caveats to the install? Just rebuilt the system after unrelated 7.4 issues and don’t want to wreak havoc on my IT guy.
I’m developing it on Centos 7.6 so it should work just fine
