5

Rendered output color not matching

I’ve been testing capturing through HDMI, and everything seems to be working pretty well except the color rendering.  The color as displayed in screenflow seems to be fine, but when it’s rendered to file or to Vimeo, colors are off pretty dramatically. this only happens when I capture the HDMI feed into screenflow, if I capture it with Quicktime and then place that into screenflow I haven’t had any problems.  

This doesn’t affect the screen capture colors at all. 

I would be great to use ScreenFlow to capture 4k video from a decent camera (have tested it with several Sony cameras), but need to figure out why the color mismatch and if there is a way to prevent it.  On the video am working on one clip capture at the end rendered’s fine, but all the other clips seems to render like the attached file. (left is screenflow, right is rendered file opened in QuickTime)

Catalina 10.15.2, ScreenFlow 9.0.1. Using a BenQ 271 and a NEC 302W display (both high gamut displays).

Thanks for any thoughts.

157replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view

    Export to desktop and use Apple ProRes and compare. 

    Wayne Fox said:
    I’ve been testing capturing through HDMI

     Sorry but this seems incomplete since you would need an HDMI capture device. The device itself could have impact.

    If it's fine in ScreenFlow but only changes in export perhaps there's a color space change between what the device is capturing and the export.

    It's probably not best to compare within ScreenFlow to an export file played in Quicktime.

    You might want to compare a camera capture through input device capture software to ProRes vs ScreenFlow export to ProRes.
     

    Like
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view

    Device is Elgato Camlink 4k. I’ve been using it for a while, and with the new screenflow 9 it is listed as a supported device. I”ve used it with over software with no issues, the file always matches what the camera captures on the SD card perfectly. I’ve even created one video using ScreenFlow where I switch between the video from the SD card and the HDMI/Quicktime feed, and the changes are not detectable. (video here if anyone is thinking of trying out the CamLink https://youtu.be/n0A-vQ1VBGE , the part that I do the switching starts at 3:45.) Obviously this would be a nice workflow boost to record straight into screenflow instead of having to capture outside of screenflow and then import the files.

    As far as the color issues, if the rendered video played on the same device doesn’t exhibit the same color it would be pretty hard to manage a workflow to produce output.  And if you couldn’t trust that when you upload the video to YouTube or Vimeo it would be reasonably close to what was displayed it would be problematic.  

    The comment was more to see if anyone was experiencing something similar and had been able to track it down.  I’ve seen some other color anomalies for example if I restart the computer, and open a project, the color is always off.  If I drag the window over to the other display then back to the display it was opened on, it corrects. This is a new behavior since version 9 was released.  Not a big deal and Im sure related, but easily could be something unique to my particular setup. It might have something to do with high gamut monitors such as the NEC 302w or the BenQ 271 that I”m using, as the visual results is similar to issues with other software not being able to render sRBG 8 bit images correctly when these higher “adobeRGB” monitors came out several years ago.

    I may have something odd in my screenflow install as well, so I may try to uninstall and clear out all preferences and see fi that’s any help.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view
    Wayne Fox said:
    If I drag the window over to the other display then back to the display it was opened on, it corrects.

     If you can show that, specifically that the display changes on the same monitor before/after being dragged that would be interesting. It might indicate an issue with GPU handling. That itself may not impact output though. That would only be a display issue.

    How you export the file may be a factor. ProRes vs H.264 and H.264 itself may be different between "normal" and "fastest" (which is using hardware acceleration). Each can impact the color. This is why how a file is exported is a factor.

    Monitors only impact how it is displayed and, given different calibration, unless you use a hardware calibration tool or know how to do precise software calibration, they rarely match.

    The best comparison is to compare a camera source file vs an unedited ProRes file in the same player on the same monitor.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view

    Wayne Fox Perhaps capture from the Elgato into its own capture software or into Quicktime directly. Compare that with the same file imported (not captured) into ScreenFlow and then exported as Lossless ProRes. Compare both in Quicktime on the same monitor.

    That will compare the Quicktime captured file with the same file processed in ScreenFlow and exported without significant additional processing.

    Like
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view

    CraigS I’ll grab a few videos of it happening. Tonight I moved it to the other window, and it didn’t fix, but then when I resized the window it suddenly corrected. Both of my displays are high bit high gamut AdobeRGB displays, and while calibrating is done in a “normal” way with an xRite i1Display and the manufacturers proprietary software (SpectraView II for the NEC 302w and Palette Master Element for the BenQ SW271) by nature these displays manage most of the calibration internally and don’t rely only on an ICC profile like most consumer displays.

      As I mentioned all of these problems are a new behavior with ScreenFlow 9.0.  I also have these problem when connecting to my NEC PA272 at my office.  It seems various things will suddenly fix the problem but on a few occasions the only fix was to open the laptop lid, move the Screenflow window over and then drag it back. Can you remind me of the best way of reporting this and providing the videos to Telestream? 

    I’ll continue working on seeing if I can understand more what is happening with HDMI capture input into screenflow and color issues.  I’ve had no problems with imported video from camera files (which are from Sonys, H.264, or HDMI captures with Quicktime  (which are Apple ProRes 422) and any color rendering problems, (most of my videos are a mix of camera capture as well as screen capture). What’s really odd is two files captured via HDMI into screenflow render differently, without any changes that I”m aware of.  Visually the problem is identical to what happens when I open a document and have to move it to the other display and back ...very oversaturated.  In this video I am just finishing I have a number of clips capture via the HDMI, and to get them to render adequately so I can upload the video to YouTube, I’ve had to reduce saturation to 70% on some of them, 80% on others and 90% on some.  I totally stumped as to what would cause a variation, maybe some experimentation will shed some light on it.

    Like
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view

    CraigS I just found the link to report to Telestream from the message you left in another thread (regarding the problem with the single file). I gather up some notes and upload some videos of this issue, then make the report.  Thanks for your help.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view
    Wayne Fox said:
    isually the problem is identical to what happens when I open a document and have to move it to the other display and back

     It sounds almost as if it's related to ScreenFlow and GPU use. See what the developers say about that. Post your case number here so I can track it.

    Like
  • Interesting thread. I came across it when looking in Google for color issues with Camlink devices in Screenflow 9.1. There's definitely an issue.

    In the screenshot, the left part is me recorded via Quicktime on Mac (Mojave). The source is a Fujifilm X-T3 connected to an Elgato Camlink connected to my Macbook pro. On the right, you see the same camera, via the same cable and the same Camlink, but recorded directly into Screenflow. My face looks a lot redder and a lot more saturated (and also not as sharp, al though the latter could be just that I was moving more). The Quicktime rendering of the colours is how it should be. The one in Screenflow is almost unusable. Any ideas as to why/how this is happening?

    Like
  • UPDATE: I thought I'd try to import the file I recorded in Quicktime in Screenflow and after importing, it looks just as bad in the timeline. Why would the same file look differently (and OK) in Quicktime and not in Screenflow?

    Like
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view

    It could be another screenflow issue I’ve been having.  When I open a document, the colors are usually wrong, especially if there is any video included.  Dragging the document to another screen and back almost always causes the colors to pop back to normal.  Here’s a video that demonstrates the problem.  vimeo.com/385171674

    I’m not sure how to correct it if you only have one display, although what I found as far as this color problem is concerned it will render out correctly despite what it looks like. (Unlike the other color problem with HDMI video which will render out poorly and require’s using color controls, mainly reducing saturation to get it to look OK.

    Like
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view

    Regarding the problem of captured video via ScreenFlow, I’ve done quite a bit of testing now, and it seems for me it is only happening when I also am capturing my BenQ display.  As long as I don’t capture that display, the video is acceptable, perhaps about 5% darker than QuickTime capture.  I’m not sure why.  Interesting thing, if I capture video via ScreenFlow and it has the bad color, when I open the document that particular video clip will look normal color, but any other video clip (via SD card or QuickTime capture) will look terrible.  Once I move my window to a different display and back, the ScreenFlow capture looks bad, and the other video captures looks normal.  In either case, when rendered it looks the same as it does once I correct the on screen color by moving the display (as I show in the previous post).  Here’s a video that demonstrates what seems to be happening in my case.   https://vimeo.com/385113828

    Like
      • sheriffderek
      • Evil Design Educator
      • sheriffderek
      • 1 yr ago
      • Reported - view

      Wayne Fox I'm trying to confirm the same results as you. I definily see a bigger shift when recording WITH the screen at the same time. But I also see some degrading with just the camera too.

      Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view
    Piet Van den Eynde said:
    Why would the same file look differently (and OK) in Quicktime and not in Screenflow?

     Because different decoders handle files differently. 
    You can play back the same file in Quicktime, VLC and Telestream Switch and they will look different. We'd recommend Switch because it's designed for Quality Control file analysis and there are similarities between its decoding and ScreenFlow.

    That said, you should be able to compare a source file in Quicktime and the source run through ScreenFlow and exported to Apple ProRes and they should be close.

    Like
  • Wayne Fox I'll try that monitor change trick. What I experienced is also a difference in output color. But I'm also experiencing that when I import a video recorded in Quicktime and I add it to a timeline where the first part was recorded directly with Screenflow, both recordings will look bad in the timeline but when exported from Screenflow, the Quicktime section of the recording looks slightly better again, whereas the Screenflow part still looks bad.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view
    Piet Van den Eynde said:
    but when exported from Screenflow, the Quicktime section of the recording looks slightly better again

     This may be related to the reason why I suggest comparing the file in Quicktime and then the exported source file from ScreenFlow in Quicktime. Judging the file while it's being used for real time decode and playback in ScreenFlow is not ideal.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view

    Wayne Fox 
    Rather than complicate things please start with my recommended test.
    Source file in Quicktime.
    Same source file in ScreenFlow, exported to Apple ProRes and compared to the source file in Quicktime.

    You may want to test this with a single monitor setup. The goal is to remove variables.

    Like
  • CraigS said:
    This may be related to the reason why I suggest comparing the file in Quicktime and then the exported source file from ScreenFlow in Quicktime. Judging the file while it's being used for real time decode and playback in ScreenFlow is not ideal.

     Ok so the issue is not just with Camlink. I recorded two clips with my iSight camera. One in Screenflow, one in Quicktime. Again, the Screenflow recording in Screenflow looks much too contrasty and saturated. It clips a lot of highlights where there is still detail in the Quicktime version. I understand different codecs can make files look differently, but in this case, it looks like the Quicktime codec is a lot more neutral than Screenflow's. I'm seeing the same in Wayne's screenshots. With the same experiment using the Camlink, I had set my Fuji cameras up to a very soft, low contrast film simulation. The Quicktime direct recording was a close match, Screenflows recording again way too contrasty and saturated. After exporting to Prores, it still looks bad. Does this mean I cannot use Screenflow to record video? Any suggestions on making the Screenflow files reflect the output of my cameras better? Correcting with the - limited - color controls in screen flow does not work. They are too coarse and the file is already much to contrasty/clipped to remedy.

    Like
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view

    Not trying to complicate things, and I have spent at least 10 hours testing various scenarios to try and understand exactly what is going on in hope to provide the developers some useful information when reporting the issue. I haven’t mentioned all of the things I’ve tried that didn’t make any difference in this thread.  Regarding your suggested test, I’m trying to understand exactly what you mean, but it sounds like you want me to compare an external source file opened in Quicktime against the same source file imported into SF then exported as ProRes.

    Originally I thought the problem was rendered output didn’t match what I saw on the screen.  Since then I have discovered that rendered output will always match the screen as long as I have made sure to “correct” the color by moving it from one display to another and back.  In my case, this  happens on documents that contain video that has been imported into screenflow, but it may or may not happen on documents that are screen capture only.  So the problem isn’t related to rendered output, but more to incorrect colors being displayed when a document is opened. this is a new behavior since ScreenFlow 9.

    exporting from screenflow as ProRes has no effect on the color, all exports regardless of  format (ProRes, H.264, etc) color is virtually identical.    If the file was created outside of ScreenFlow (SD card or HDMI capture with other software) and imported, it will render identically from screenflow as it appears opened in QuickTime. The comparison posted in the last video demonstrates that, as these are rendered screenflow documents and the only segments of video with bad color are those captured via HDMI with ScreenFlow, and so far if my BenQ display is being also captured. eGPU or internal GPU (16” MBP) makes no difference. If I open the monitor window while capturing, the color in that window is normal, and will not match the color of the actual file in screenflow once captured.

    most of the time, external video files that have been imported into SF will look terrible when the document is first opened and oddly enough video captured within screenflow will appear normal. Once color is corrected by moving the document, the external files will then be visually fine, the screenflow capture video will be oversaturated between 10Q% and 30%. Rendering the file will always render the colors to match those on the screen once the color as been corrected as well, whether or not the video is rendered before or after fixing the incorrect color being displayed on the screen by moving the window.

    I’m currently trying to document all of this in some meaningful way so I can provide feedback to developers.  

    Like 1
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view

    CraigS 

    CraigS said:
    Because different decoders handle files differently.  You can play back the same file in Quicktime, VLC and Telestream Switch and they will look different

     I’ve never seen a case of a decoder making a 30% difference in saturation. I’ve worked with all of those as well as FCP, Premiere and a few others.  What’s odd to me is color in the monitor window is fine, and doesn’t match the video once it’s in the timeline.

    Like
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view

    Piet Van den Eynde Just curious as to which MacBook Pro you are using, I’m on the new 16”, wondering if the new graphics card in the 16” might be an issue.  I still have a 2018 MBP and a 2013 Mac Pro, I may just run some quick tests to see if the problem remains.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view
    Wayne Fox said:
     I’ve never seen a case of a decoder making a 30% difference in saturation.

    You're talking about two different issues. The display in a program is not the same as comparing source vs exported file which is the processing chain. 

    Since you see to have different results with different monitors perhaps there's a GPU issue?

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view

    It seems several issues are being conflated.

    1) Comparing a file in Quicktime Player vs the same file exported from ScreenFlow.

    2) Comparing a file in Quicktime Player vs the same file being played in ScreenFlow.

    3) Recording a source in Quicktime vs recording a source in ScreenFlow and comparing them in each.

    Each is different. They are not the same processing. 

    Ultimately,  it is 1 above that impacts delivery.

    If there are issues with 2 or 3 that may well be something worth investigating but they are definitely different processing. 2 involves different decoders. 3 involves potentially different outputs from the camera and different codecs.

    For example, a webcam may have both MJPEG or YCbCr and it's possible what a program pulls from the webcam may have some impact.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 2 yrs ago
    • Reported - view
    CraigS said:
    3) Recording a source in Quicktime vs recording a source in ScreenFlow and comparing them in each.

     Using my Facetime camera:
    I recorded and saved it from QT.
    I recored and exported it as Apple ProRes from ScreenFlow
    In Quicktime Player, The QT MOV and the ScreenFlow MOV look basically the same.

    While the Facetime camera recording looks more saturated and "contrasty" in ScreenFlow, the export does match the QT recording when both are played in Quicktime.
     

    Like
    • Wayne Fox
    • Wayne_Fox
    • 2 yrs ago
    • Reported - view
    CraigS said:
    Using my Facetime camera: I recorded and saved it from QT

     This is only happening on video recorded through HDMI (both in my case and in Piet’s case).  I’m using an Elgato Camlink 4k, he is using an Elgato Camlink.  Camlink is listed as a supported device in ScreenFlow 9. Both of us are using mirrorless higher end cameras with HDMI out (I’m using various Sony’s, he’s using a Fuji), similar to how other video content is created by many.

    Regarding your previous statement, I can’t see why an HDMI feed captured  in Quicktime (or any other capture software) and then imported into ScreenFlow appears normal and renders normal on export, yet the same video captured within screenFlow will appear oversaturated, and will only appear somewhat normal when exported (via any codec) if saturation is reduced between 10 and 30% (and why that varies is puzzling as well). The differences you mention from processing should be subtle and not objectionable. 

    While there are multiple issues they seem related in some manner, the only reason I say this is because a screenflow captured video will look perfectly normal when the document is opened, and all other video will look terrible (and usually screen capture looks odd as well) , until something happens to “correct” the color (such as moving the window to another display). Then the Screenflow captured video looks terrible (and will render as it looks in this case at any time, making it unusable.) and the other video looks (and exports) correctly.  Whatever is making the video look “wrong” when opened is a 100% exact opposite problem to captured HDMI video, correcting whatever is wrong with the HDMI capture when the document is initially opened. As I mentioned when recording, color in the monitor window looks fine, yet the video captured is oversaturated (usually by about 30%).

    Because this problem is most likely not very common (or there would be many more complaints), your mention of the GPU is something worth testing. The new 16” MBP discrete graphics GPU is new to the Mac lineup, and I never tried capturing HDMI until recently after having switched to the new 16”.  Additionally the behavior upon opening a document may be coincidental with my new 16” MBP, which was about the same time I switched to ScreenFlow 9. Probably not many screenflow users on the new 16" MBP that are also trying to capture HDMI video.  

    I have a 2017 MBP and am going to move my license over and run some tests.  I haven’t reported this problem yet because I just can’t seem to figure out anything that might help the developers isolate it, and unless I can, I”m not sure they can do anything about it. 

    I’ll update with results of trying a different Mac/gpu combination tomorrow.

    Like
Like5 Follow
  • 5 Likes
  • 2 mths agoLast active
  • 157Replies
  • 778Views
  • 16 Following