Blackmagic Forum

I have shot a lot of V-Log L footage in 10-bit 4:2:2 DNxHD 25fps 185Mbps with my Panasonic GH4 (4K downconvert to 1080p 10-bit 4:2:2 via HDMI) and it looks fine when playing it back on Quicktime player or Sony Vegas Pro 13, but when I import it into DaVinci Resolve 12.5, all these chromatic aberrations appear and they get more noticeable if I apply any LUT or change the videos input color space. I noticed this when using the previous version of Resolve. I have included a image of the video frame and a close up of the fence behind the boats so you can see the CA.

DaVinci Resolve 12.5:





Quicktime (unedited video from QT player showing fence with less abberations):



I know the lenses I was using were not CA free, but they were not as bad as they appeared on Resolve as any thin line showed either green, red or purple lines on them. Is there anything I can do to stop this happening? I have tried changing the color science on project settings to any of the color spaces, but that has no effect.

Could be wrong, but not sure I would classify this as a chromatic aberration. I think this is more of a moiré pattern because it is occurring on the fence in your footage.

Not sure of the solution but knowing it's moiré might help with troubleshooting. For instance, perhaps something was introduced in the downconversion, or perhaps the footage was captured this way but for some reason QT is not displaying it. It can be tricky to nail down. Sometimes applying a subtle blur to the affected area is enough to make it go away.

JP Perry wrote:Could be wrong, but not sure I would classify this as a chromatic aberration. I think this is more of a moiré pattern because it is occurring on the fence in your footage.

Not sure of the solution but knowing it's moiré might help with troubleshooting. For instance, perhaps something was introduced in the downconversion, or perhaps the footage was captured this way but for some reason QT is not displaying it. It can be tricky to nail down. Sometimes applying a subtle blur to the affected area is enough to make it go away.

I am not sure that QT is displaying it wrong. I was able to edit the footage in Sony Vegas Pro 13, export it as a MP4 file and the issue didn't show up the way it was in Resolve when playing it back on different players like Windows Media Player, Media Player Classic and VLC and when I uploaded test footage to YouTube, it didn't have this issue either when I played it back.

Here is a close up crop of part of the image in my first post, showing a street light, this time edited with a curve adjustment and color satuation boost, both done in Resolve and Sony Vegas Pro 13. You can see the problem well here.

Sony Vegas Pro 13:



Resolve:



It doesn't look like a moiré issue to me. I know the GH4 is prone to slight moiré and has aliasing issues on thin lines, especially when downconverting 4K to 1080p but I don't think this is causing the issue.

Out of curiosity, what happens if you open the footage in Nuke, After Effects, or Photoshop using 32-bit RGB processing? Do you see the same chromatic abberations?

Resolve processes all media in RGB 32-bit float internally, so the chromatic abberations may be being introduced in the conversion from 4:2:2 YUV to RGB. This could explain why you're not seeing the abberations in Quicktime or Sony Vegas (I don't know how Sony Vegas handles footage).

Hmmm. Can you elaborate on your workflow: "4K downconvert to 1080p...via HDMI"? What is your Resolve timeline resolution?

JP Perry wrote:Hmmm. Can you elaborate on your workflow: "4K downconvert to 1080p...via HDMI"? What is your Resolve timeline resolution?

I think downconvert the op was referring to occurred out of the camera via HDMI to an external 1080p 4:2:2 recorder. This would make the source footage 1080p, not 4K.

Out of curiosity, what happens if you open the footage in Nuke, After Effects, or Photoshop using 32-bit RGB processing? Do you see the same chromatic abberations?

Resolve processes all media in RGB 32-bit float internally, so the chromatic abberations may be being introduced in the conversion from 4:2:2 YUV to RGB. This could explain why you're not seeing the abberations in Quicktime or Sony Vegas (I don't know how Sony Vegas handles footage)

Unfortunately no,, since I don't have any of those programs. Sony Vegas uses 32-bit float in either video levels 2.222 gamma or linear 1.000 but only displays 8-bit color and not 10-bit like Resolve.

JP Perry wrote:Hmmm. Can you elaborate on your workflow: "4K downconvert to 1080p...via HDMI"? What is your Resolve timeline resolution?

I was using an Atomos Ninja 2 recorder which only records 1080p max resolution. I set my Panasonic GH4 to 4K 100Mbps and set the output of the GH4 via HDMI to 10-bit 4:2:2 and down convert 4K to 1080p, which takes the 4K image and converts it to 1080p so it can be recorded via an external recorder and it gives better quality than just setting the camera to 1080p mode and no downconvert. 1080p gives worse quality from the GH4 because of how it uses the sensor compared to 4K mode.

In resolve I am setting the settings to 1080p 25fps, Video bit depth 10-bit, Color Science: DaVinci YRGB Color Managed or YRGB. I have also tried both DaVinci ACES and ACEScc with no difference in the color fringing..

David J McCormick wrote:

Out of curiosity, what happens if you open the footage in Nuke, After Effects, or Photoshop using 32-bit RGB processing? Do you see the same chromatic abberations?

Resolve processes all media in RGB 32-bit float internally, so the chromatic abberations may be being introduced in the conversion from 4:2:2 YUV to RGB. This could explain why you're not seeing the abberations in Quicktime or Sony Vegas (I don't know how Sony Vegas handles footage)

Unfortunately no,, since I don't have any of those programs. Sony Vegas uses 32-bit float in either video levels 2.222 gamma or linear 1.000 but only displays 8-bit color and not 10-bit like Resolve.

JP Perry wrote:Hmmm. Can you elaborate on your workflow: "4K downconvert to 1080p...via HDMI"? What is your Resolve timeline resolution?

I was using an Atomos Ninja 2 recorder which only records 1080p max resolution. I set my Panasonic GH4 to 4K 100Mbps and set the output of the GH4 via HDMI to 10-bit 4:2:2 and down convert 4K to 1080p, which takes the 4K image and converts it to 1080p so it can be recorded via an external recorder and it gives better quality than just setting the camera to 1080p mode and no downconvert. 1080p gives worse quality from the GH4 because of how it uses the sensor compared to 4K mode.

In resolve I am setting the settings to 1080p 25fps, Video bit depth 10-bit, Color Science: DaVinci YRGB Color Managed or YRGB. I have also tried both DaVinci ACES and ACEScc with no difference in the color fringing..

you can download nuke non commercial version for free, same for fusion

it looks more like a color subsampling issue to me.
perhaps somewhere in the processing pipeline the 4:2:2 subsampling isn't combining/interpreting the color information of two adjacent pixels horizontally, but on the vertical axis, or using a wrong subsample alignment, or the subsampling metainformation is misinterpreted in another way.

could you please make a short unmodified sample available, to analyze/reproduce this [interesting] issue?

Does the problem persist if you Deliver the clip through Resolve, or is the problem only visible on the viewer?

Martin Schitter wrote:it looks more like a color subsampling issue to me.
perhaps somewhere in the processing pipeline the 4:2:2 subsampling isn't combining/interpreting the color information of two adjacent pixels horizontally, but on the vertical axis, or using a wrong subsample alignment, or the subsampling metainformation is misinterpreted in another way.

could you please make a short unmodified sample available, to analyze/reproduce this [interesting] issue?

Here is the video from the screenshots I posted, its unedited, DNxHD 185mbps 10-bit 4:2:2. It is 2.8GB though: https://mab.to/HRTMkvDWO

Does the problem persist if you Deliver the clip through Resolve, or is the problem only visible on the viewer?

The problem is visible when I render the video with Resolve as well as showing on Resolve. I don't know if this helps or not, but I found a LUT plugin for Sony Vegas and tried it and the LUTs showed the same aberrations on the videos as Resolve does.

David J McCormick wrote:

Martin Schitter wrote:could you please make a short unmodified sample available, to analyze/reproduce this [interesting] issue?

Here is the video from the screenshots I posted, its unedited, DNxHD 185mbps 10-bit 4:2:2. It is 2.8GB though: https://mab.to/HRTMkvDWO

thanks for the sample!

it's very easy to reproduce your issue on relove 12.5 for windows.
and i'm not able to see similar artifacts in other applications (natron etc.)
but i have no idea, how to fix it -- it seems to be a serious resolve issue.

I can confirm running Resolve 12.5.2 on OS X 10.11.6. The issue does not appear in either After Effects or Nuke.

I did a couple tests rendering the clip out of AE. When rendered as a DNxHD185X or ProResHQ, and brought back into Resolve, the issue remains (even though it wasn't visible in AE). If it's rendered out as a ProRes444 or EXR file, the issue disappears in Resolve.

Definitely seems to be something going on with Resolve reading 4:2:2 chroma subsampling.

I can confirm running Resolve 12.5.2 on OS X 10.11.6. The issue does not appear in either After Effects or Nuke.

I did a couple tests rendering the clip out of AE. When rendered as a DNxHD185X or ProResHQ, and brought back into Resolve, the issue remains (even though it wasn't visible in AE). If it's rendered out as a ProRes444 or EXR file, the issue disappears in Resolve.

Definitely seems to be something going on with Resolve reading 4:2:2 chroma subsampling.

Thanks for testing that. Next chance I get, I'll do several recording tests. I'll record an 8-bit 4:2:0 internal 4K video on the GH4 and try 10-bit ProRes externally from the HDMI and see if that is any different over DNxHD and see if this happens again in Resolve with those different codecs.

Scott McKenzie wrote:If it's rendered out as a ProRes444 or EXR file, the issue disappears in Resolve.

yes, it does not happen if you transcode the files to prores444 by ffmpeg either -- e.g.:

Code: Select all

ffmpeg -i NINJA2_S001_S001_T004.MOV -c:v prores_ks -profile:v 4444 -pix_fmt yuv444p10le -c:a copy ninja-prores444.mov

btw.: it's also not happening on 4:2:0 h.264 files. -- as long as this issue isn't solved, you may get better results by just using the internal 4k recording of your camera.

Scott McKenzie wrote:Definitely seems to be something going on with Resolve reading 4:2:2 chroma subsampling.

indeed, it looks like a nasty bug, which will affect many productions!

Using a Flanders monitor with the BMD mini-monitor, the issue is not visible. It IS visible on the rendered output. I have never seen this issue with any other Avid codec footage. Very strange!

I tried most available codecs on my Mac and only converting to 444 codecs directly by using Quicktime resulted in a clean image when imported into Resolve.

I also shoot with a GH4 and I can not reproduce the issue with any of my footage. I have tried converting my 4k footage to every HD codec and image sequence etc.
I suspect there is something non-standard in the supplied file.

This is a very interesting thread. I agree with many of the posters that the problem most likely lies in how Resolve internally converts chroma subsampled YUV to RGB. This is a messy operation on the sunniest of days, and I have seen many programs struggle. But Resolve differs from other NLEs in that you can't avoid the YUV to RGB conversion, even if delivering YUV. As the previous poster mentioned, he did not see the problem when monitoring on a Flanders monitor with a BMD card. This is not too surprising because that chain likely bypassed the internal RGB conversion. But as he also discovered, the problem showed up in a render. That is perhaps the main reason that Resolve is not a full fledged NLE (yet). If you just want to edit YUV footage with no grading applied, then you need to use an NLE that can stay in YUV space.

I would be very interested if the following workflow experiences the same problem. Transcode the GH4/Ninja footage to TIFF outside of Resolve. I recommend After Effects or Nuke since their RGB science is unparalleled. Then bring the TIFF sequence into Resolve. If you don't see the problem, then I would suspect you know for certain it is something related to how Resolve upscales the chroma channels.

Michael Del Papa wrote:I would be very interested if the following workflow experiences the same problem. Transcode the GH4/Ninja footage to TIFF outside of Resolve. I recommend After Effects or Nuke since their RGB science is unparalleled. Then bring the TIFF sequence into Resolve. If you don't see the problem, then I would suspect you know for certain it is something related to how Resolve upscales the chroma channels.

Similar to the EXR and ProRes444 exports from AE, transcoding a frame to a tiff sequence out of AE doesn't show the same issue in Resolve.

I am also monitoring through a BMD UltraStudio Express to an FSI BM230 and noticing the colour issues inside Reslove. It is very difficult to see and you need to push in on the image to get a good look.

If I have time, I might try to look through other 4:2:2 source footage that I have kicking around from different projects and see if a similar issue appears there or if there is something specific to this clip.

Issue may be related to 4K downscale with external HDMI HD recording. As others have suggested, test all aspect of workflow but my recommendation would be to use Vegas and an off-line editor, generate an EDL/AAF/XML and finish in Resolve. That way, you are working with original material in Resolve, not a Vegas output.

Also, you really need to be monitoring Resolve material with at least a 3G 'mini monitor' plugged in [4:2:2] (or any of the 12G Decklinks which offer 10/12bit 4:4:4 4K at upto 60P) and a 10bit calibrated monitor in 1:1 mode. Without at least a mini-monitor card and 10bit reference monitor, you cannot be sure whether the issues you are seeing are source related or simply monitoring issues.

Craig, I am not sure I understand your comment. Others have downloaded his sample clip and reported that they see the same issue on a color managed system unless they convert the footage to EXR/ProRes444/TIFF first.

I am not 100% sure if it is the same problem, but I saw similar chroma artifacts when testing 422 color bars that were nearest neighbor subsampled from a 444 image (i.e. clean boundaries). Different colored artifacts show up along the vertical boundaries because that is what needs to be interpolated for a 422 image. The horizontal boundaries are always clean, no surprise. And his posted images are similar in that they show problems along vertical boundaries.

just a few additional notes about this issue:

1.) you will see this wrong colors, even when you completely desaturate the footage in another application before importing in resolve.

2.) it also happens, if you only take a small crop from the clip

3.) it's not only visible on your screen, you will also see it in resolves vectorscope:



here is another tiny 3sec (0.3MB) desaturated and denoised crop for testing.

it will look like this in resolve:

in any other application it's only gray.

I'm seeing the same thing on my end with desaturated footage.

An interesting factor, if I use the Pixel Zoom function on my FSI monitor (running 4:2:2) to zoom into the fence instead of zooming in through resolve the issue is not visible. Running the footage at 1:1, it is visible on resolve's internal scopes, but my FSI's built in scope at 4x Gain with the image cropped just to the fence doesn't show any colour disparities.

The most interesting part of this issue for me, is that the preview through the BMD mini-monitor is perfect and clean, while the Resolve viewer and rendered media file show the issue.

I have many YUV clips from Avid in DNxHD 4:2:2 (all resolutions both mxf and mov containers) and also many GH4 H264 4k and HD clips, plus 4k down-converted clips and Atomos outboard recorded files doing exactly the same process as the OP described. NONE of the other clips I have, have EVER displayed this issue, which is why I don't think it's a Resolve issue with YUV decoding but possibly a slightly non-standard recording that Resolve can't correctly decode, but the attached hardware (mini-monitor) CAN decode correctly.

I think the OP should put in a bug report to BMD, and supply the problem file for them to examine.

Michael Del Papa wrote:Craig, I am not sure I understand your comment. Others have downloaded his sample clip and reported that they see the same issue on a color managed system unless they convert the footage to EXR/ProRes444/TIFF first...

Sorry, I should have read further before responding but it's interesting that the issue does not appear via Peter Cave's mini-monitor/Flanders (assuming SDI) at 1:1.

Craig, no problem. It is looking like my suspicions were off mark as well, and that this could be a bug in how Resolve decodes this particular footage.

As I said before, this is a very interesting thread, and I am very curious to see how BMD responds.

Michael Del Papa wrote:As I said before, this is a very interesting thread, and I am very curious to see how BMD responds.

that's true!

i generated a synthetic test pattern of all possible 4:2:2 gray value pixel pairs, to estimate the amount of effected contours and to understand better where to look out for this error.

here is 1 sec 4:2.2 proress clip (12MB) and the test pattern as tiff file (4MB)

it will look like this in resolve:

Tried your test pattern, but was unable to see this effect, no mater what settings.

Martin Schitter wrote:
i generated a synthetic test pattern of all possible 4:2:2 gray value pixel pairs, to estimate the amount of effected contours and to understand better where to look out for this error....

it will look like this in resolve:

Martin, should we be able to see clearly the diagonal stripe in GUI screen as well as grading monitor driven by Decklink SDI?

Frank Glencairn wrote:Tried your test pattern, but was unable to see this effect, no mater what settings.

did you use the 4:2:2-clip or the raw test pattern? the issue seems to be related to color subsampled input, therefor it's only visible if you import the clip.

and you have to look at the GUI display or rendered output!

just a few words about the significance of this synthetic test.
it's not just a simple gradient. if you look closer, you will see a pattern of vertical lines running from black at the top of the image to withe at the bottom located on a gradient in the background that runs from black at the left side to white on the right. this particular arrangement will sweep over all possible 10bit gray value combinations in a two-pixel 4:2: subsampling area within the 2048x1024 pixel matrix.

here is small crop of the test pattern:


the result looks more cogent, if you increase the saturation:


it makes more more clear, which gray value combinations trigger the artifacts.
it's happening over the whole luminosity range and both values have to be quite similar, but the affected share of value combinations unfortunately looks higher than expected to me.

Okay, just tried the clip, now I can see it.

It's probably a QT problem.

I exported the tiff to see what happens

AVI > uncompressed > 4:2:2 > just fine
QT > uncompressed > 4:2:2 > colored patterns

Frank Glencairn wrote:AVI > uncompressed > 4:2:2 > just fine
QT > uncompressed > 4:2:2 > colored patterns

i found the issue in uncompressed AVI as well,
but h.264/AVC intra 4:2:2 against expectation doesn't show the artefacts -- no matter if you use mp4 or quicktime containers.

Hi there,

finally joining in

A little round up of my results so far:
-> it does not happen with every 422 footage, but so far with every QT-based 422 footage and a few others
-> DNxHD and DNxHR, both in MXF containers, also color the ramp
-> AVC Intra and XAVC decoded by Adobe Media Encoder both won't color the ramp

I uploaded my test-files: http://fuke.it/nextcloud/index.php/s/hVwDh7tdal4hfLx
Note that the _ffmpeg and _pr422hq are NOT encoded by me, but I downloaded them here (and/or in the Slashcam forum).
I used the Prores HQ file as basis for all conversions (not the tiff). Some of the formats are bound to their resolution that's why not all are 2K.

I also tried using different Prores-tastes encoded on a Mac in AME, all but 4444 did the colour-artifacting too. Even when I took the Prores 422 as basis for the 4444, it did not happen there.

So far I'm under the impression that FFMPEG, or lets say its not-so-good implementation, has something to do with this. Because it seem to happen a lot with FFMPEG encoded media (even if it's not QT)

Best,
Lucas


//edit
Important to note is also the versions of the Resolves... on my PC (where I checked and produced all the data from the Link) I use 12.5.2.
At work I tried this issue on OSX in 12.5.1 as well as Resolve Lite 11.3.1. Same behaviour also in the old version

Lucas Pfaff wrote:-> it does not happen with every 422 footage, but so far with every QT-based 422 footage and a few others
-> DNxHD and DNxHR, both in MXF containers, also color the ramp

Sorry, are you saying that it happens even with video that is natively recorded to DNxHD or DNxHR by a camera or an external recorder -- or only to video that has been transcoded to DNxHD or DNxHR using ffmpeg?

If you are saying the latter (ffmpeg), do you know if this happens with video that is transcoded to DNxHD or DNxHR using either Resolve or Avid Media Composer?

Thanks

Hi there Blake,

sorry I wasn't very clear we talked about this issue in a different forum too and I came over, so lots of my post must be misleading! :/

I don't have any possibility to record natively into DNxHD or DNxHR here, so I have no idea about that.
I only transcoded to these formats, but not with ffmpeg, only with AME. So far, I didn't tested footage that was encoded with Resolve (as I barely get back into Resolve after that), and I don't own an Avid to check

I just want to point out that there GH4 has a well documented problem recording with magenta artifacts. This is supposed to go away almost completely using the external 10 bit add-on. Internal 8 bit with log makes the footage almost unusable.

There are hints of this error in the non log modes as well.

So is this a resolve problem, a gh4 problem, or a QuickTime problem?

Lucas Pfaff wrote:Hi there Blake,

sorry I wasn't very clear we talked about this issue in a different forum too and I came over, so lots of my post must be misleading! :/

I don't have any possibility to record natively into DNxHD or DNxHR here, so I have no idea about that.
I only transcoded to these formats, but not with ffmpeg, only with AME. So far, I didn't tested footage that was encoded with Resolve (as I barely get back into Resolve after that), and I don't own an Avid to check

Thank you for that clarification.

I notice this problem long time ago when i exported DNG files as QT422 and then import it to Resolve. That time i thought it was caused by bad debayer or resize, so i just decide don't fooling myself and always force best scale and debayer settings on export and use QT444 for cache and export. But after reading this thread i see that its some kind of Resolve internal problem.

Testing this ramp i find that if i export tiff to 422 footage with Resolve i don't see this artifact in other apps or video players. But if i put that exported 422 footage to Resolve again and export to 422 again i start to see that color rainbow in all apps and players.
So seems its internal 422 implementation problem in Resolve. And i think its better to use 444 always for export and for timeline cache settings.

Gian Salucci wrote:I just want to point out that there GH4 has a well documented problem recording with magenta artifacts. This is supposed to go away almost completely using the external 10 bit add-on. Internal 8 bit with log makes the footage almost unusable.

There are hints of this error in the non log modes as well.

So is this a resolve problem, a gh4 problem, or a QuickTime problem?

Hi Gian,

the problem is that this doesn't happen with internal recording, but with the external recording. The problem here is not LOG or the GH4, it's a general problem with quicktime based 422 material. And it's completely reproducable with material encoded on a computer.


Hi Dmitry,

so far this seems only to happen with QT-based formats, not general 422 exports. For caching etc I also think that 444 makes more sense, but this issue becomes problematic when your camera material is native 422. This is a horrific issue that needs to be solved ASAP

..or just stay away from QT.

That's why I never run into this problem before - I just don't use QT anywhere in my workflow.
And yeah, I know - for some of you, this is not an option.

Apologies in advance, but I think I may still be confused here.

I believe you wrote the following:

Lucas Pfaff wrote:-> it does not happen with every 422 footage, but so far with every QT-based 422 footage and a few others
-> DNxHD and DNxHR, both in MXF containers, also color the ramp

Lucas Pfaff wrote:I don't have any possibility to record natively into DNxHD or DNxHR here, so I have no idea about that. I only transcoded to these formats, but not with ffmpeg, only with AME.

Lucas Pfaff wrote: The problem here is not LOG or the GH4, it's a general problem with quicktime based 422 material. And it's completely reproducable with material encoded on a computer.

so far this seems only to happen with QT-based formats, not general 422 exports.

From merely a troubleshooting point-of-view, I'm trying to reconcile the statement that the problem only seems to happen with QT-based formats, but that it also happens with DNxHD and DNxHR codecs in a non-QT MXF container (that you transcoded with AME). If the problem is also happening with MXF files that are not being decoded by QT, then I am having trouble understanding how it is a QT problem and not possibly a larger issue.

I can confirm that I have the same issue with MXF files. Seems to be a YUV 422 issue. I have sent a report to BMD to watch this thread.

Peter Cave wrote:I can confirm that I have the same issue with MXF files. Seems to be a YUV 422 issue. I have sent a report to BMD to watch this thread.

Ok. That makes more sense.

So, in summary, the problem does not seem to be associated with the codec, with the container, with the use of LOG, or with the bit depth. However, it does seem associated with the color space (YUV) and the color subsampling (422) of the file.

Is that correct? If so, that's still a pretty big issue.

Not exactly - if you export that Tiff file in Resolve to uncompressed AVI 422, it looks just fine. So it looks like it's not 422 per se.

i'm still puzzling over this issue.

right now it looks most plausible to me, that resolve is using some very strange and error prone heuristics to decide between bt.709 and bt.601 an the matching coefficients.

just have a look at this test patterns and video samples to detect bt.601/709 color matrix related settings/errors:
https://obsproject.com/forum/resources/ ... harts.442/

the results in resolve look quite different compared to other applications.

Frank Glencairn wrote:Not exactly - if you export that Tiff file in Resolve to uncompressed AVI 422, it looks just fine. So it looks like it's not 422 per se.

no -- if i put the tiff (i ihope, we are referring the same file) on a timeline and export it as 10bit YUV AVI and import it in resolve (version 12.5, win8.1) again, it shows false colors!

the only 4:2:2 variant that works as expected, seems to be h.264/AVC intra.

Martin Schitter wrote:i generated a synthetic test pattern of all possible 4:2:2 gray value pixel pairs, to estimate the amount of effected contours and to understand better where to look out for this error.

Great job, Martin. I downloaded your test patterns and loaded them into Resolve. While the TIFF does not show any artifacts, the ProRes 422 version shows the exact same artifacts you posted on both my GUI and my monitor. FWIW, I am monitoring with a IP4K HDMI-out directly to an Eizo CX241.

Also, when I load the ProRes clip into After Effects, I don't see the same artifacts.

Hopefully, BMD will weigh in on this issue.

Until then, this is why I use TIFF in - TIFF out for my Resolve workflows.

Michael Del Papa wrote:

Martin Schitter wrote:i generated a synthetic test pattern of all possible 4:2:2 gray value pixel pairs, to estimate the amount of effected contours and to understand better where to look out for this error.

Great job, Martin. I downloaded your test patterns and loaded them into Resolve. While the TIFF does not show any artifacts, the ProRes 422 version shows the exact same artifacts you posted on both my GUI and my monitor. FWIW, I am monitoring with a IP4K HDMI-out directly to an Eizo CX241.

Also, when I load the ProRes clip into After Effects, I don't see the same artifacts.

Hopefully, BMD will weigh in on this issue.

Until then, this is why I use TIFF in - TIFF out for my Resolve workflows.

do you guys tried in teh settings to evaluate the "error" with the [sharpen] and the [smoother] settings of resolve?
does the anti-alias produce any effect?

waltervolpatto wrote:do you guys tried in teh settings to evaluate the "error" with the [sharpen] and the [smoother] settings of resolve?
does the anti-alias produce any effect?

i tested most of this project settings, but they to not change the behavior.
but what's more significant, it does not happen, if you use 4:2:2 h.264/AVC intra footage, regardless of all this other settings. in this format it also does not matter, if the file is using/tagged as bt,709/bt.601/smpte240m, which is otherwise a very troublesome source of subtle color reproduction errors -- especially if you have to use apple codecs and containers.

btw., walter, could you please try to reproduce the bug on professional linux editions of resolve?
up to now we only know, it seems to behave the same on windows and mac os and various resolve releases, but nobody could check it on linux.

Martin Schitter wrote:

waltervolpatto wrote:do you guys tried in teh settings to evaluate the "error" with the [sharpen] and the [smoother] settings of resolve?
does the anti-alias produce any effect?

i tested most of this project settings, but they to not change the behavior.
but what's more significant, it does not happen, if you use 4:2:2 h.264/AVC intra footage, regardless of all this other settings. in this format it also does not matter, if the file is using/tagged as bt,709/bt.601/smpte240m, which is otherwise a very troublesome source of subtle color reproduction errors -- especially if you have to use apple codecs and containers.

btw., walter, could you please try to reproduce the bug on professional linux editions of resolve?
up to now we only know, it seems to behave the same on windows and mac os and various resolve releases, but nobody could check it on linux.

Apologize, but I have problem to get material from the web and load in the box here (MPAA/security reasons...)

i rather not getting myself fired... usually when i check something in the Linux boxes is either with material i already have or i check at home on a PC...

waltervolpatto wrote:Apologize, but I have problem to get material from the web and load in the box here (MPAA/security reasons...)

never mind! -- i really value serious security awareness...

maybe someone else will check it on linux.