jan1

Now I can see the difference it makes... First scope is with gamma correction, and then white pivot applied. It brings it down, but leaves the upper range straight. Second scope is same gamma correction, but no white pivot, instead white trackball correction to extreme (-84). This leaves the gamma curve across the whole range. White Pivot is also much more aggressive than white point.

Hi Adrian, Thanks for that explanation. I'll play with it again with the gamma in the mix. In Mistika 8.11 you have to switch the Color node to HDR to get kneesoft, correct? There is no other way to enable kneesoft in the current version?

Here are the controls for the above scope....

I'm now intrigued by the less understood Pivot controls in the Primaries color tab. From the manual it states that these controls (which exist for white point and black point) control the range of action for the track ball. That seems to make sense, similar to pivots for contrast. However, in practice their behavior does seem to be as logical as I would assume. If you change the white point pivot, and then change the white trackball, nothing is different. Similar on the black side. However, if I change the black trackball and modify the white pivot I see some changes. To figure out what is going on, I created the standard gradient so you can watch it in the rgb scope. From that it appears, that the white Pivot is simply added as a linear offset to the black point correction and vice versa. It doesn't really constrain the the range. I would have expected that if constrained the range that only a section of the slope would be impacted while the rest remained as is. And as a result the line should start to bend accordingly, either hard or soft (with knee soft). But that's not happening. Interestingly enough, once you have a white Pivot you can counteract it with the black Pivot at opposing values. So I must be mis-understanding something. The manual only has a very terse description. This is the scope of my test. You could achieve this result by simply dragging the white trackball up, and it would stretch the line to a steeper angle. Except this correction is a -11 on the black trackball, inverted by a -2 on the white pivot. What's curious is that in this math, there doesn't seem to be any benefit to using Pivot, if you could achieve the result by modifying the opposing trackball to the same effect. What am I missing?

I do end up using the mouse, but mostly because the panel options are somewhat limited. The knobs on the Tanget do give you a better tactile connection to the changes you make. The biggest limitation of using the panel with curves is that you can add the default points but you cannot move them horizontally. So you are stuck with the default spacing. Which especially if you're trying achieve roll-off in the shadows or highlights is not helpful. It would be nice to have an option to add a single (or an extra control point) and be able to move it on both axis. I think I would use the panel a lot more for curves then.

If you use Zoom, if you have (or can get) and AJA ATap, you can take the SDI signal from the FSI and feed it to Zoom as a camera feed. I've done this on several occasions. That's better than sharing your GUI screen. If you can to keep doing it, then you can look into other streaming platforms more geared to our industry (like Streambox, etc). There was a thread on LGG discussing them. But most of them require more expensive hardware and/or subscriptions.

Possibly. But that would just create a very fragmented set of tools that's difficult and expensive to maintain. I think a lot can be learned from Baselight who has done a nice job of making the color space journey an integral part of the tool and workflow, rather than some entry/exit point conversion like most other tools. Resolve now offers the CST OFX plugin which people start using heavily, but it is a band-aid, not a properly engineered workflow. The real answer is to change the platform to be color space aware and then adapt all the tools so they can work in a variety of color spaces with that knowledge. But that's no small feat. I think we'll see some, like Baselight, lead in this space, and others may technically support ACES, but may not be as practical in that realm for the time being.

Was just playing with that. The simpler way of doing that for dailies, is actually not Propagate (as there are no meta-data filters), but Match & Paste. Do the base correction for your dailies and paste to everything. Then to do for example reel based tuning, refine one clip for the reel, copy, and then match & paste based on reelname. That is also great if you need to match two cameras.

Actually Mistika should be good for dailies. It has the ability to render out individual clips in the Output page. Bring in all the media, create a string out, add a color node on one clip, make adjustments. Copy node, select all other nodes and paste, which will automatically create individual copies for each clip. Render out as individual clips. Done. If you need to make smaller adjustments for different reels, or scenes, the storyboard and propagate functions would make this pretty easy.

Yes, it still uses it. Just in a lock-down mode where you can't customize the mapping.

I agree that the way the 'A' (alt) button works is awkward in some cases. That works if you have both hands on the panel, but I often work with one hand on the mouse/pen or keyboard and the other on the panel. If 'A' was a toggle (or could be preferenced into a toggle) that would be nice. Not just on the Wave2 but also on the big Elements.

That sounds weird. Are you on a Mac or PC for that? In theory the Tangent Elements and Wave 2 should be quite similar in that regard as they go through same mapper. I've had no problems with it. You do mention Resolve connecting to it in the interim causing issues. I had some cases lately where Resolve doesn't completely die. Even though it looks like the app is closed, if you look in the task manager there is still a process hanging around that I have to kill. So maybe that is your issue - that some other app still is attached to it, and that's what the reboot clears out? I think the Tangent Mapper you can also see if an app is still attached, can't you?

I tried that and it doesn't work. I was unable to achieve a ranges setting that would allow the highlights to be lowered from their peaks. The problem is more complex than just a range adjustment. There's a mismatch with colors being in a linear space with controls that are designed for log space. In the case of the Baselight's BaseGrade operator the operator actually internally does color space transforms on both ends to unify the way the data and the controls interact regardless of color space. A comparison would be to surround the color node with a 1D LUT on both sides to temporarily change the gamma of the data for the controls. While ACES has a lot of great advantages, it does make it hard for some of the current tools to work with it. I do see a lot of people work in scene referred work by simply unifying on the Arri LogC color space instead. Maybe that's a better way to go for now.

Played with that. The White Pivot is for Primary though, right? I was more looking at the Bands. Specifically I had some highlights need 100IRE which in Rec709 I could easily use the White band to adjust without impacting the rest too much. But in ACES, nothing will unstick the whites around 95 IRE and pull them down. When I have a regular Rec709 color node, it looks like by default blacks impact the bottom 10% and the whites the top 10% (as visualized in the width of the slope handle in the range graph. In ACES the blacks appears to impact the bottom 70% and the whites are beyond the top.

You mean the ranges in the Color Node. Yes, I did play with that, and it seems to influence. But not sure if it does enough and how to set it to deal with a very different color space, rather than just pivoting with in the range.

I was just working on a project where I setup the ACES workflow as usual: Clip, then Unicolor mapping from camera to AP1/ACEScct, then ColorGrade, then ACES ODT to map to Rec709. I noticed that if I make adjustments in the bands the highlights and whites largely seem to affect the same values in the waveform. I am assuming that the ranges that divide the bands 'highlight' and 'white' are calibrated more to a log color space rather than the AP1 color space and thus not sitting right. Same with the softclip roll-off. Is there a fix for that or a way to have the bands react properly? If I replace the ACES Unicolor and ODT with just a camera LUT everything works as expected. I know there's been lots of discussion to make certain operators colorspace aware. Baselight's 'Base Grade' operator is a great example of this working. But even if it has to be done manual, it would be ok for now.

That's a good find. I'll have to try this out and play with the mapping to improve it. Cheers, Jan

Just sharing some insights from a support ticket we resolved. On the last project I was working with a standard scene referred ACES workflow, RED Raw footage, Unicolor and ODT. As explained in most tutorials I added the ODT at the top of the stack. That turned out to have some unforeseen consequences. I'm losing the ODT in some storyboard functions, and particularly in the gang solo. I also lose the ODT when in the vector paint. After debugging we determined that neither was a bug. The story board/gang solo is by design. The vector paint is turned into a feature request. But the main take away, and reasons for this post, is that when you work with ACES it actually is more proper to put the ODT into a display filter rather than at the top of the stack. Of course you have to carefully monitor settings and make sure the display filter also applies to renders. In a way that is logical as it puts the display transform outside of the grade. In Resolve the ODT is set in the project settings, not the grade, so it's generally the right thing. But it's not the intuitive way and not how it's explained in most of the tutorials if memory serves. Thanks Cristobal and Rocio for helping sort through this.

I can't offer any comparison to Scratch. I've maxed out on the number applications I can juggle mentally due to non-color workflows I also do. But I can offer that it took me being committed to Mistika and having now done two dozen client projects to finally get more comfortable and knowing all the tricks that make you efficient. I think there are reasonable equivalents for all the things you're listing. I've had to do some manual clip replacement for a conform and it is all there. I think because Mistika's UI is so different from traditional NLEs it's less intuitive the first time around. Mistika shines if you make it your tool of choice and commit the time to it. But it's definitely not a good choice for the occasional user, or someone that turns to it for certain jobs because they do like a specific feature. I've started becoming more fluent and found it to be quite powerful and more productive than Resolve. That said, there definitely are quirks in the UI that could use refinement to even things out, make things more efficient. The UI is still very much centric to a system that is always setup a certain way due to the previous closed nature of Ultimate. The adjustment to a more diverse user base in terms of hardware/software configurations will take some time, but be critical to the success of that user base, and is also somewhat urgent to take advantage of the opportunity and not turning off too many potential adopters like yourself.

Based on your answers, I was successful copying just the timeline specific files from the private folder of the old project to the new project and then copying the paint nodes from the old .env to the new one and everything came across perfectly. You saved me a lot of time ? Jan

Ah that makes sense. Thanks Javier and Cristobal. These are all the little nuances one has to learn on a new system. After quite a few client projects I'm making progress in getting familiar with Mistika and knowing how to use it well and efficient. It's now too later to make a copy of the project, since we already graded again. I'll see if it's possible to copy private data selectively just for those nodes. If not I'll just have to re-do them this time, and know what to do next time. In Resolve there is a function where you can export a .drp file which is an archive of a project that can always be imported even in different versions. Is there a function in Mistika (or some instructions) of what all the files are that need to be archived for a complete project to be restored? Of course it would be easy to archive the whole project folder, but often it contains renders and other temporary files that take up unnecessary space. So it would be nice to separate the required from the transient files. Thanks as always, Jan

The client decided to go in a different direction on the color of a project and we're re-doing the color as a result. One challenge is that there are a few clips that had skin cleanup with vector paint that I'd rather not re-do if possible. I created a new project, opened the old .env file and copied selected parts of the timeline onto the new timeline. Including the paint vector nodes. But it doesn't look like any of the actual strokes came over. Are they not attached to the node directly? I see that there is a load/save file. So I thought maybe I need to go to the old project and save each paint vector into a file? But unfortunately if open the old project (copied over from another system) any stack with the vector paint in it appears to ignore it. The eval tree doesn't even show the vector paint. My guess is that this is because I copied the files from my old system to the new system, and something didn't come along for the ride. I could try to go to the old system and run Mistika there and save individual files. But I'd also have to move my license back temporarily to do that. Becoming complicated. It does pose the question, so archiving a project by it's .env file will not be be enough. What has to be saved to retain vector paint data?

This is the latest release version 8.10.0. I will file a ticket and provide the devs the details. Thanks for all your insight and help in testing this.

I will experiment with that. My main drive is a 1TB .M2 SSD and I've finding 2.4GB/s transfer speeds. I'm in agreement on that. The difference exists, but it requires extreme conditions to surface. Given the price difference it is a luxury but not a necessity to run with the Quadro card. I may keep it for the extra memory more than anything. If I were to start from scratch, the Titan RTX is probable the sweet spot with 24GB VRAM but a better price.

That makes sense about not returning memory and using internal memory management. Keep in mind that this totally find on a dedicated system, but could post problems in case of Boutique where other apps may also be running. That means I'll have to quit Boutique instead of switching to Premiere or other software that may make extensive use of the GPU. At times as I conform I do keep multiple applications open. In this scenario there may be in fact a memory leak or software bug. This is running the first clip in my new test. It starts playing at 7fps the moment you see the VRAM start ramping up. Once it hits the max at 24GB and flattens out, it continues to run, but the playback drops to 2-3fps (all within a single clip). Presumably Mistika cannot find any new memory and has to start swapping memory out. Maybe a case where buffers do not get re-used properly. Render speed within the same clip should remain constant absence anything changing, right?