Input Quality (color, Sharpness, Clarity) Is great. However Program output is horrible. Why?

Hello @JoPhi and also @Oliver_Boinx. We have spent the afternoons yesterday and today testing out JoPhi’s ideas and others to improve the color of our Mimocalls, and we did find a way of addressing the pretty vast color difference between PowerPoint slides when run in the host layer stack and those shared by an outside presenter. This is important to us because our clients (particularly one we are about to do a huge project for) have certain branded colors on their slides and would expect them to be reproduced accurately in the videos we create.
Based on the advice we received in this forum, we’ve tried:

  1. Adding a black layer at the bottom of our layer stack (perhaps to correct for the fact that our image had an alpha channel) - no change
  2. Output in Prores 4444 (as well as 422 and H264) to see if the 4444 codec would make a difference - no change
  3. Using JoPhi’s SuperPresenter TV show which uses PIP Windows for the presenter and slides instead of the Presenter2D and a PIP window like mine - increases clarity(!) - but color still an issue
  4. Played with using different color profiles on our machines - ran through every one - various changes - none a very close match
  5. Tried calibrating the display - no positive change
  6. Tested running tv show on hard drive vs from cloud - no change
    We found the color correction filter on the Mimocall in the source panel and added it onto the Mimocall we were using for the guest PowerPoint. We were able to use the settings there to get very darn close to a match to standard color bars. See images.
    So now, we do feel like we have two ways we can go with our presenters - operate their PowerPoints within Mimolive ourselves as hosts OR have them present via two Mimocalls (one for presenter and one for presentation).
    It would be great if the color matched out of the box, but having this filter does make what we want and need to do possible.
    Wanted to share out where we are at since the community has been so helpful to us–and we’ve learned a ton along the way. - Elissa

Thank you so much for sharing the results. So, combined with the pip-window-presenter and the color correction filter, the result is much closer to the original.


Thank you especially @jophi - seeing how you set up your Mimolive layers and some automation really showed us how this could be used. Hoping to develop these skills further. :grinning:

1 Like

I tested it also.

Basically, I can confirm all your experiences.

(left: original, right: mimoCall)

I added your settings. The Image was too shiny and too bright, so I added an additional color-corrector, to get this out.

The colors are “still” different, because of a generation problem.
mac Compresses highRes (or RAW) to V9/h264 / other mac reconstructs the image and displays it. This way isn’t lossless. Now the question is: Can we live with it?

Since your exploration, dear @MiniMattersEL, I’m able to!

Thank you so much,

Ps: It looks color graded, don’t you think?

Yes it does @JoPhi that is not an option im my broadcasts because adding the color corrector introduces noise to the footage. the only option is for it to be fixed.

What i find really weird was the preview window and the program window are very much different. The preview window shows the footage coming into “Mimolive” correctly, However when it goes live and goes over to the program window it degrades color, video gamma, quality etc. Can someone try that please?

Please provide an example document, as I did. At least I might be able to reply to it with an idea for a workaround which could work until it is fixed. :slight_smile:

And please: never get confused by the preview. it’s a fast pre-rendered “whatever”, to get an idea what the result could be. It’s there as a reference. You could bring your PGM-preview to exactly the size of your layer-preview to compare a match, or you could output it to a real studio monitor (sdi-output), to compare it with a real studio Monitor (before input). Besides: Your input-signal could also be too rich/intensive in colors, so color information can be lost/clipped or reflected back within the final format/rendering. Compare also JPEG vs. BMP vs. Canon RAW vs. PNG vs any other still image format.)

Please compare this:

a. the preview

b. the recording:

c. try it yourself:

Why is 4:4:4 missing? <= it was a 4:2:2 recording.
Why is 4:2:2 so strange to see? <= It’s a screenshot from a scaled version of the recording. (After pressing spacebar.) However, this forum could (additionally) also reduce the quality of the image. Maybe to save disk space.

All the best,

1 Like

Today I explored a difference between Google Chrome, Safari and Firefox. When you use Firefox. Does this also change something for you in case of the colors?

I will look into browser differences on our next round of testing–thanks for that thought. In the meantime, I had found this article - Gamma Correction and Why It Matters and wondered if the difference we are setting between our Mimocalls for people - just fine quality - and the PowerPoints could be due to a gamma correction problem. Like perhaps the Mimocall is expecting a person rather than a graphical presentation, so the Source has not been programmed to be suited to the graphics? Just a thought - I am no expert at this. Do you think that maybe we need a Mimocall source programmed for graphics in addition to the one we use to bring in people?

I think similar and did a bunch of tests today. Finally, Firefox worked for me the best - out of the box - while remote screen recording. It sounds strange, but I think that Safari and Chrome are causing the troubles.

Sorry for the delayed reply - we’ve been very busy with proposals and editing for clients and had to take a pause in our testing. :slight_smile: But, some news, alas. We were not able to replicate the success you seem to have had with Firefox. Same kind of washed out color. What you see here is a PIP window of me sharing a PowerPoint slide with color bars (via PowerPoint as an application, so I can run the slideshow) to my partner and the resulting program output. You can see the colors are washed out - and this is true of the output as well. On the other hand, because she has control of the “frame” when she hosts the Mimolive, the red color of our client’s logo is replicated properly. We have not yet tried Safari, but we are clearly having this color issue when sharing graphics via a Mimocall in both Chrome and Safari.

1 Like

Oops - forgot the screenshots and including here.

Also, just thought of this, but we’ve been using dual Mimo calls for presenter and PowerPoint, so that we can have both onscreen as in the example below - beta/non-beta. Perhaps this would work through Firefox just by the presenter sharing their screen–maybe that’s what you did, @JoPhi ? However, we do need both the presenter and the PowerPoint for what we need to do.
It would be great if this color issue could be looked into and maybe a source created for Mimocalls with graphics as opposed to people? (if this might be a solution - I don’t know) We do have a work-around by manually adjusting the colors with a filter, as written above, but obviously it’s not ideal and this doesn’t work for some other people with different needs.

1 Like

Thank you for submitting the images and the detailed description. :hugs::hugs:

Also, testing on M1 hardware lets only survive Firefox while beta-testing, Safari and Chrome are bringing mimoLive to a crash, and I don’t think that mimoLive is the reason or is responsible for it.)

I also tested both the same time: Screen-Capturing and WebCam. I’m sure that Safari and Chrome do have troubles to integrate WebRTC properly. And it seems to be that Firefox on Mac is doing this better than C/S.

I’m sure that boinx is heavily working on this, probably to work around these troubles, which are maybe caused because of Chromes/Safaris non-standard usage of color profiles or color ranges/subsampling).

I also hope that no one has to use color correction or to remind to avoid a certain browser in future. It’s a beta. I think at the final version nobody has to.

My explored M1-crashes/hangs (while using Safari/Chrome) are another topic, but maybe it’s also related to the lack of a propper integration by Google/Apple. With Firefox it seems to work fine.


Sorry to hear about the M1 issues. We are not on M1 machines and, in fact, are sticking with Catalina rather than upgrading to Big Sur at the moment. I do wonder what would happen if we upgrade to Big Sur, but would still like to postpone the upgrade–as other things except for this are working great.

1 Like

On the static Mac I’m also on Catalina. And yes, I’d not change this. :slight_smile: :slight_smile: :slight_smile: The M1mbp16GB I use for prototyping and as a toy. Sure, I can’t wait for the first native beta!! :smiley: :smiley: :heart:

The mimocall is geared more towards being fast than colour accurate I think. Which, in all fairness, makes sense. It’s a heavily compressed signal anyway and low latency is the most important. Colour correction on input is your best bet. But I think you might have more luck with the levels effect, that lets your adjust the rgb levels.
There are ways to remote control powerpoint in a browser window over internet as well, though in my experience not everyone manages to use those. But if you test with the speakers, at least you can use some presentations locally and reduce the number of calls in a show.

Seems like a slight change in gamma. The same happens when you put an effect on a source. You can add a colour correct filter to each source and adjust the gamma to 1.2 to compensate. Or, expose the source just a bit lower.
Interestingly, it doesn’t happen in the program preview in the main document window, but it does in the multiviewer. And in the stream that goes out.
Not ideal, but I haven’t noticed this during production. Most streaming platforms end up slightly altering the image anyway, so it is very hard to keep tight control of contrast and colour.

Thanks, Oliver. I played with the Levels effect, but interestingly could not get a complete and accurate correction to color bars, even when those had the black, white and gray that should allow an accurate match. Don’t know if you can replicate this and, if so, what does it mean that it can’t be corrected in this way? (I got a better but not perfect correction using that color correction filter.) Welcome your thoughts.

Hi everyone, mimoLive has been plagued with color issues from the very beginning and we always assumed that this issue had to do with Quartz Composer. However, last week, we had a lucky break and stumbled upon what we were doing wrong in handling frame buffers. We released a new beta yesterday which has changes in a number of places in mimoLive to address color issues. The worst error was in mimoCall and it has now improved very much. There are still areas in mimoLive that we haven’t looked at yet, but it is already a big improvement. Please test the 6.1.1b1 beta and let us know where you still find color issues.

1 Like