[Primary Controls Pivot Values]

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.

[Primary Controls Pivot Values]

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?

[Primary Controls Pivot Values]

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

 

[Primary Controls Pivot Values]

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?

 

[Tangent Wave 2 Support and Tangent remap options]

On 3/24/2020 at 7:53 AM, Cristobal Bolaños said:

Indeed, it will be a big loss, however I don't know how many users control the curves from the tangent, rather than from the mouse. 

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.

[Remote Workflows]

On 3/13/2020 at 1:06 PM, jeff@dungeonbeach.com said:

I think since my session is on Tuesday I may just use zoom (regular screen sharing that is not high quality). Of course it is not ideal because the client will see the entire interface, and I will have to keep toggling to full screen (what's the shortcut again for that???).

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.

[ACES and Bands]

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.

[Tangent Wave 2 Support and Tangent remap options]

On 3/12/2020 at 9:52 PM, jan1 said:

If you need to make smaller adjustments for different reels, or scenes, the storyboard and propagate functions would make this pretty easy.

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.

[Tangent Wave 2 Support and Tangent remap options]

On 3/12/2020 at 9:12 AM, Rakesh Malik said:

Scratch is great for dailies, which Mistika isn't, and I haven't figured out how to automate what I do in Scratch using Workflows yet.

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.

[Tangent Wave 2 Support and Tangent remap options]

On 3/12/2020 at 9:12 AM, Rakesh Malik said:

Does Resolve even use the Tangent mapper? I was under the impression that it didn't, which prevented anyone from updating the mediocre Resolve implementation.

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

[Tangent Wave 2 Support and Tangent remap options]

On 3/12/2020 at 12:30 AM, jeff@dungeonbeach.com said:

Is it possibly to get the alt button to behave more like caps lock? Tangent limitation? It's actually not so ergonomic to press and hold the alt key and press another button on the panel. Especially when holding a stylus, it becomes a big operation. I really wish alt was a toggle. 

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.

[Tangent Wave 2 Support and Tangent remap options]

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?

[ACES and Bands]

On 2/29/2020 at 8:29 AM, Cristobal Bolaños said:

So, try lowering the ranges accordingly to around a 70% for ACES.  

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.

[ACES and Bands]

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.

[ACES and Bands]

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.

[ACES and Bands]

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.

[Tangent Wave 2 Support and Tangent remap options]

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

Cheers,
Jan

[ACES Workflows]

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.

[New Machine for Mistika Boutique]

On 12/16/2019 at 2:16 AM, Rakesh Malik said:

Conforming in Mistika is kind of a pain. That has actually been the main impediment for me in using it on more projects. The tools are all there, but they're clunky as all hell, so generally I don't much like conforming in Mistika. There's no elegant way to view the reference video along side or over the raw video, and there doesn't appear to be a particularly straightforward way to simply replace a clip. In Scratch, you select the replace mode, hunt down the clip you want to replace the erroneous clip with, and drop it in place. Then you just type the right timecode into the "in" field for the clip, and Bob's your uncle. I wish it were that easy in Mistika. Hopefully there's a nifty trick there that I don't know about yet... 

Most of the time however I can get a pretty clean conform from Resolve using AAF, so for dicey conforms I sometimes just do the tedious part of it in Resolve which has by far the best editing toolkit of the three (no surprise) and export an AAF. That's usually almost 100% spot on, and saves a lot of work, though I think it's a bit comical to be using Resolve as a conforming tool ?

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.

[Copying Paint Nodes]

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

[Copying Paint Nodes]

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

[Copying Paint Nodes]

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?

[GPU Benchmark for testing Mistika Boutique's perfomance]

On 12/12/2019 at 7:45 AM, Javier Moreno said:

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? 

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.

[GPU Benchmark for testing Mistika Boutique's perfomance]

On 12/12/2019 at 7:32 AM, Javier Moreno said:

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.

I will experiment with that. My main drive is a 1TB .M2 SSD and I've finding 2.4GB/s transfer speeds. 

On 12/12/2019 at 7:32 AM, Javier Moreno said:

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. 

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.

[GPU Benchmark for testing Mistika Boutique's perfomance]

On 12/12/2019 at 7:13 AM, Javier Moreno said:

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)

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?