Javier Moreno

Sorry I think I was missing a key point of your previous message: >> Is there an apply button at the bottom that I can not see ? Yes, there is an "Apply" button at the bottom of the File->Options panel. If you can not even access that area, you can edit this configuration file manually: C:\Users\Your_user_name\SGO AppData\VR\localPReferences.xml Edit that file (for example with the Notepad) and change the scaleForScreens setting to 1.10: <scaleForScreens>1.10</scaleForScreens> Then save it and open Mistika VR Hope it helps Javier

That setting requires to restart the application. When you reopen Mistika, are those settings showing your last custom values or are they reset to the original values ?

Sounds like it didn't autoconfigure correctly. Go to File-Preferences and just switch off the GUI rescaling option (or set an specific value different than 1 to avoid autoconfigurationi, for example set 1.1)

Hola, De momento no es posible insertar metadata externa en los códecs. Solo se propaga la metadata standard de edición (timecodes, frame rate, etc). En el futuro si que está previsto incluir capacidades de manipulación de metadata. Saludos Javier

Hi David! Thanks for the feedback, it was very useful and we have found what it is. We expect to solve it in the next maintence release Cheers, Javier

Hi David, We are trying to reproduce the problem, but unfortunately it is not happening in our systems. We just fixed a bug with the Move node than confused us a bit, but it is not in the Copy node and we can't reproduce it. If not yet, please could you try the same Workflow having both folders in the system disk? (just to discard that it is not related with potential filesystem or network refresh latencies ) Any other detail you could think to reproduce the problem? Cheers, Javier

Well this particular case clearly involves a creative process, and to be honest I'm an engineer and not an artist. So I can't anticipate how many iterations will be needed. I guess it will take "until the client likes it".

Do you mean the render speed? If it is HD it should render in a few seconds, or at 4k less than one minute. But I suppose you may want to do some intermediate renders and adjustment iterations , as judging the optimal speed for something like "sparkles" appearing and disappearing sounds to require realtime playbacks to evaluate it properly. It is not a case of applyng the effects and forget . Basically you will need to go trough several "try and refine " iterations, rendering a realtime preview each time.

I would recommend to experiment with a Noise and Glint effects. Animate the noise parameters, use a color grade to adjust contrast and pass the result to the Glint effect. Also compose with the original image. But each software is going to produce a different result, if you like kiraKira I would recommend to use it and then compose the results in Mistika.

Hi Rakesh. Thanks for oyur honest review, it is very valuable feedback for us. About the clip replacement in Mistika, I am wondering if you could use this technique: 1 - Hunt the replacement clip wherever it is. If you select it in the media browser it will appear in the Source Monitor, or if you prefer to select it in the Tiemeline then press Ctrl+C (Copy) to send it to the clipboard, which in Mistika just is the Source Monitor) 2 - Put the Record Monitor (red bar) in the head of the clip to be replaced (or in any other in point you want it). Alternatively type the timecode for it directly. 3 - Press SourceMonitor->Overwrite (the icon with a red clip going down into a green clip). Or directly use its hotkey (B) while having the pointer in the Source Monitor (hotkeys like this affect the marks of the panel where you have the pointer at that moment). Whe you do that, the new clip will we placed at the record monitor position while also overwriting whatever was in there. The other icons near Overwrite are to insert (making space) or paste on top (similar result to a replace but you don't lose the original clip). In all cases you can also use the yellow marks in the source monitor ( "i" and "o" hotkeys ) to define which part of the incoming clip you want to insert. Or just type its In / Out timecodes in there as you seem to prefer. Regarding the interface, we are working in new capabilities to make it more scalable (for example to better support 4K GUI monitors). For example I think you could use a new scaling feature to mach the bottom screen of your laptop to the bottom part of the Mistika interface (menu panels in general), an let the upper screen for a clean view of the Timeline and Visual editor images. This scaling feature is still in development, but I belive a raugh version is already operative in your Mistika version (i suppose you have 8.10, the one in our website ). It would work as follows: 1 - In Windows, define a single continuous desktop with one screen on top of the other 2 - While in MistikaConfig-> General->AdvancedOptions, select the Interface->Use Scaling button, and for Mon-1 select the scaling factor as neccesary to fit the Mistika botton panel in the bottom display of the laptop (But do not activate "Two Monitors", as this proposal is a for a single (but elongated) monitor. This scaling feature is in development, in your version it can still have some refresh issues and some low res and aliasing at non integer scale factors in some widgets, but we hope to solve all this for next version 8.11. Please let me know if it works, I am curious. Sadly I do not have such wonderful laptop to try by myself. That dual screen laptop seems to be a nice one! Javier

For performance reasons some information like VectorPaint strokes, titles, morph, and data from 3rd party plugins are not saved in the .env file (which is a text file) but in the PRIVATE folder of the project as binary data (which is faster). If you copy a project to other system you need to copy the whole project folder, not just the .env file.

That's an interesting test, thanks for the feedback. BTW for that particular format, a key parameter is the Codecs-GPU frames. In general it should be 1 for GeForce and 2 for the Quadro. (you could also try with 3, but I am afraid it could be a waste of memory)

Well, it also depends on each client. The one case where Quadro is mostly preferred is for client attended sessions, as in those cases it is very desirable to have as much realtime playback performance and stability as possible.

In a case like this you should reduce the memory related parameters ( Max cache memory, ring buffer, pipe units, render units, encode threads ). That will free a lot of memory for other applications. I totally agree, that memory curve is typical of memory leaks. Otherwise it should look like a staircae . What is the exact date of your Boutique version? First thing I would recommend to render the source images to other format and test , as this test will show if the memory leak comes from the decoder or from one of the effects (in that case you would need to remove effects one by one to see which one is causing it) Please if you don't mind open a support case about the memory leak so developers can investigate it, in that way it is much more efficient for them

In all those examples the bottleneck is the effect processing, not the upload and download of images to/from GPU. So the full duplex can not help on them because at such low FPS speeds the PCie bus is infrautilized anyway. To take advantage of it you would need to build an example that is close to realtime, for example a more simpler stack that can deliver speeds close to UHD 60p. In that scenery is where having the Quadro can make the difference between realtime and non realtime. Also, if your storage is fast enough I would recommend to use uncompressed images like Mistika js format , exr raw or dpx. This is to avoid dependence on 3rd party codecs like Arri in a benchmark that is supposed to be about GPUs. Apart from this, one difference that should already be noticeable in your exanple is the advantage of the double amount of GPU memory in the Quadro, as you said that using all of it. Even with that the GeForce has a much better performance / price ratio and it is more than enough in may cases, there is no doubt about it.

Hi Jan, Depending on what you are doing Mistika will not return graphics memory buffers (and neither buffers in RAM). This is made on purpose: In order to avoid memory fragmentation Mistika has its own memory manager , it will keep memory buffers and only reuse them with images of the same size. The collateral effect is that if your timeline contains images of different sizes or different color spaces it will use more memory, but it is because the performance is the priority by default. If you need to reduce memory usage you can reduce related parameters in mConfig (Max Cache memory, ring buffer, pipe units, render units, ..). Alternatively restart mistika session from time to time depending on the content Also please keep an eye on task manager about memory usage during playbacks . The memory use (both GPU and ram) should only increase between clips with different needs, not between frames of a same clip (in that case we would be talking about a potential memory leak / software bug) Please let us know the differences after testing with the other board. Your tests are very interesting.

It will use it if available, there is nothing to configure about it. To test it you can do a "complicated" playback (for example a Comp3D with some layers at a resolution that is near realtime in your system but not realtime (this is easier to evaluate in UHD 60p modes), and make sure the disk speed is not the bottleneck. Then write down how many FPS you get on each case. Use one GPU and then the other, and in both cases do one playback test to the GUI monitor and another one to the SDI output,. The GUI playback may be similar for both models (as in that case there is not need to download images from the GPU), while the playback to SDI board should be faster on the Quadro, as it can download images for the SDI output at the same time that next frames are being uploaded. Regarding the GPU selection for Mistika , an easy way to chose the GPU is to connect the monitor to the GPU you want. By default Mistika will use the GPU connected to the display where it is launched. Another way is to select the Boutique icon and use the Nvidia or graphics processor applet in the control panel to define which GPU is used for that one. Alternatively use right mouse button on the Boutique icon to open the contextual menu, there should be a menu to decide the graphics processor that is used. But this method requires to do it every time. Regarding the other question, Mistika can not use one GPU for GUI and one for processing directly. But you can launch independent render jobs (rnd files) the other GPU , either by using "PathToMistika.exe/mistika.exe -r PathToRNDFile" command in a console running in the other GPU , or by configuring a 3rd party render manager like Smedge to render jobs in the other GPU. (launch Smedge in the other GPU by using the above techniques, or check Smedge documentation for more possible ways to configure this )

Mistika Boutique is agnostic in terms of the operating system and hardware brands. Most of the software is open-gl based, which should run at similar speed on Windows and Mac. However, there are some differences in these particular codecs: - RED has launched a new Cuda decoder for R3D files. Currently it only works with NVidia boards, and Apple does not support it. But R3D files still work on Mac with the traditional decoder based on CPU, so if you go the Mac route and you need R3D just try to get a good CPU with as many cores as possible, and of the highest clock speeds. - NVidia has also launched a hardware encoder for H264 & H265. But by now Apple does not support it, so it only works on Windows and Linux Regarding Afterburner, we have not made any tests with it yet. In principle, Apple Prores formats are already pretty fast in Mistika by just using the CPU, as Prores playbacks have been troughly optimised in Mistika . With good CPUs they are already realtime at 4K 60p, and also in some 8K 24p variants. But if we see that our clients start requesting this capability of course we will try to implement it in the future. Regarding your question about our tests on Windows hardware , our developers and engineers typically test every windows version on Hp workstations (z820, z840, Z4 and Z8), also using several models of Intel CPUs and different NVidia boards. But it is also tested in other brands whenever we have opportunities. Regarding GPUs for Windows, the sweet spot seems to be the 1080ti for computers with no video boards, and the P5000 ( or even P6000) for high end systems with video boards . RTX equivalents are also great , but they are similar in speed and are probably more expensive just because they are newer. RTX have more capabilities for other markets like gaming and machine learning, , but for the particular case of Mistika they don't come with significant advantages over the previous generation. In any case just check the cost factor because it is constantly changing. Regarding the computer brand, what we can say in general is that Mistika seems to be equally stable in computers of well known brands, but we have seen quite a few support cases where custom-built computers were unstable due to using PSUs with not enough power or due to thermal issues. Those are the two main aspects to check when not using a volume brand. Also, we maintain a document with recommended configurations here: https://support.sgo.es/support/solutions/articles/1000269519-recommended-configurations-for-mistika-boutique

Also, if it is about economics a good way to save money is to use 1080ti or a P6000 (even if second hand), as the RTX does not really provide performance gains for the particular case of video processing in Mistika, only in rare cases. But If you want RTX , the RTX 5000 is probably the sweet spot. It is close in performance to RTX 6000, although with less memory. Personally, what I would do is to check how much graphics RAM you use in your most complex timeline (after working for a while on it and passing trough all the Timeline). You can see that in the Task Manager (look for GPU options). I think it s the best way to choose the right model if you are in doubt.

Regarding NVidia I do not have documentation, but it is easy to see. Just play a complex timeline (for example at 4K with a Comp3D having multiple layers and you will see) Apart from that, Quadro boards are recognized to be more stable and long lasting under heavy rendering over the time. We have barely seen any Quadro burned over the years, but many GeForce were fried. In principle the price difference still does not compensate for this, as you can always buy the next GeForce when the previous one is burned, thus having the new model and still saving money. But if you work in client attended sessions or very tight agendas you may think differently.

The main differences are; - The amount of graphics memory. If your tiemeline does not need the etxra it does not make any difference, but if it need it the Quadro will be much faster, as otherwise the GeForce will swap to system RAM or even crash at some point. - The Quadro upload and download textures in full duplex mode troufgh the PCIe bus, it can be upload image layers for next frame while downloading the previous frame at the same time. This is specially important at high resolutions, and it makes a significant difference in realtime capabilitiesplayback

Hi Jeff 32 GB can be enough for most 4K workflows, but it depends on what you are doing. For example color grading requries few RAM because it is just one effect, but complex finishing /VFX may requier a complex stack of effects. Specifically these are the points that are known to use a lot of RAM - R3D codecs are specially hungry in terms of RAM usage. A common situation is that many users are doing 4K production but they are using 6K or 8K raw camera files, which require up to 4 times more RAM. - Another situation is when using different resolutions in the same Timeline during the same session. Using different resolutions is perfectly supported but it requires extra RAM. This is because in many cases Mistika will only reuse memory buffers of one particular size for images of the same size during the same Mistika session, ( otherwise the performance will be severily reduced due to memory fragmentation). What we recommed is to load the most complex timeline in terms of the above issues and keep the Task Manager open while you work. In this way you will know how much RAM are you using exactly. Regarding the performance settings, 0 means autoconfiguration (but only for the "Parallel processing " sections). If one of those setting s is 0 Mistika will assume the number of cores of your system for that settting, except for the case of Render Units which is half of that number, as explained in the panel itself). Also, the autoconfiguration will use a limit of 24, because higher number of threads are inefficient in most cases (please note that many codec libraries also split each call into several threads, so you could easily saturate the system by going to high with these numbers). However, the optimal number for each particular situation can only be found experimentally. Also, Mistika Boutique can only use one GPU (the one were you start the software). Regards, Javier

yes it uses the render engine, but you can still have control: - If you need access to pixel values, insert a GLSL effect in a display filter from Ultima or Boutique (several workflow nodes have a display filter parameter ). GLSL is a programming language (an evolution of GL )specialised in image processing, so you can not write python code to process pixel information but i you could do it in GLSL - Regarding the metadata you mention (resolution , fps, etc) a good part of it is stored in task node parameters that you can read, and also change depending on the case. Some other metadata is not accessible as node parameters but you could still read it and change it, as a workflows project is just a text file, and also the rnd, clip metadata (.clp files for rendrded clips and .lnk for source media ) and display filters, as everything else in Mistika (there are no binary databases , just text files) . Just importing media files in Mistika Boutique will read all the significant metadata from the source media files and it will put it in ".lnk" text files in your project in a coherent manner ( a same script will work for all formats ) , so you could get it from there. However, for some of the cases I mention you will also need Mistika Boutique, not only Mistika Workflows

Not directly in Python, but you could try the following (not sure if it works for your purposes): First create a display filter in Mistika Boutique including a GLSL effect, which can load a user script written in glsl language. Then apply that display filter in a workflow node. When executing that node the image data will be passed to your GLSL code, which could do any transformation to the image as desired.

Hi Guys, This Google doc contains an introduction to the Mistika Workflows Script Editor Introduction to Mistika Workflows Script Editor It is still a draft document for the beta version. Please provide your feedback in reply to this post...