Blackmagic Forum

Tom wrote:some use? I made a living off of it for about 8 years haha.

Still use it almost every day for graphical sections of my adverts.

That makes one of us! Ha. But I have a buddy here who loves to use it and when I need some 3d work done I ask him to do it. I think my aversion to it is a form of PTSD.

Gary, have you gotten any answer/fix from BMD for the windowed HD in an HD timeline from the Ursa Mini 4.6K?

BMD really should be fixing this problem in the camera firmware ASAP.

I had a bunch of files that were shot and captured in camera as 1080p ProResHQ exhibiting the artifact and they were flagged by an unhappy client. At first I figured it was user error on the part of my client or his editor, but when I did my own testing, sure enough (as Gary proved with his wonderful documentation of the issue) the problem was real and still present in properly rendered output played at 1080p.

Few of my clients use Resolve in their post production workflows as most grade directly in their NLE (for better or worse). I fully accept that if I shoot raw the files have to go through Resolve, but to have to run even ProRes files through Resolve to apply the .drx fix is a ludicrous requirement. The whole point of shooting direct to ProRes is that it will go straight into an NLE without requiring transcode! This scaling issue is maddening and has me unable to hire out my Ursa Mini on any shoot where the scaling issue will manifest itself and Resolve isn't part of the workflow.

This is the less than helpful response I got from BMD support in an email today:

"Unfortunately at this time there is no further information available. We will not be able to RMA the camera as this is unlikely to produce a different result under the circumstances that you describe. The only advise I can give in this particular case is to make sure that the Detail level is set to none in the recording menu—this will greatly minimize artifact manifestation."

I always RTFM and have had the detail setting at zero since the option was added to the camera firmware.

Hey BMD, I think we deserve an official response here on when to expect a firmware update that will fix this silly scaling problem in camera once and for all.

Jamie, I asked Veronica for an update last week and to see if 4.0 would fix it but she didn't know anything. I'll be installing the new firmware on my camera today (after an edit session this morning) and will test this afternoon and get back to you.

I'm sorry to hear that you were nailed by a client for it... I'm lucky to be able to use the .drx in my workflow, which is to shoot 4.6k raw and then render to 4.6k prores before editing. But yes, the point of having prores in camera is to be able to shoot prores and I'm hoping to see that problem fixed (either now in 4.0 or soon in 4.x). RMA-ing the camera will not help because I'm fairly positive that it's a debayering issue in firmware.

Will get back to you later today.

Jamie LeJeune wrote:Gary, have you gotten any answer/fix from BMD for the windowed HD in an HD timeline from the Ursa Mini 4.6K?

BMD really should be fixing this problem in the camera firmware ASAP.

I had a bunch of files that were shot and captured in camera as 1080p ProResHQ exhibiting the artifact and they were flagged by an unhappy client. At first I figured it was user error on the part of my client or his editor, but when I did my own testing, sure enough (as Gary proved with his wonderful documentation of the issue) the problem was real and still present in properly rendered output played at 1080p.

Few of my clients use Resolve in their post production workflows as most grade directly in their NLE (for better or worse). I fully accept that if I shoot raw the files have to go through Resolve, but to have to run even ProRes files through Resolve to apply the .drx fix is a ludicrous requirement. The whole point of shooting direct to ProRes is that it will go straight into an NLE without requiring transcode! This scaling issue is maddening and has me unable to hire out my Ursa Mini on any shoot where the scaling issue will manifest itself and Resolve isn't part of the workflow.

This is the less than helpful response I got from BMD support in an email today:

"Unfortunately at this time there is no further information available. We will not be able to RMA the camera as this is unlikely to produce a different result under the circumstances that you describe. The only advise I can give in this particular case is to make sure that the Detail level is set to none in the recording menu—this will greatly minimize artifact manifestation."

I always RTFM and have had the detail setting at zero since the option was added to the camera firmware.

Hey BMD, I think we deserve an official response here on when to expect a firmware update that will fix this silly scaling problem in camera once and for all.

Anyone check this artifact on the new version 4 camera beta?

Gary Yost wrote:Jamie, I asked Veronica for an update last week and to see if 4.0 would fix it but she didn't know anything. I'll be installing the new firmware on my camera today (after an edit session this morning) and will test this afternoon and get back to you.

I'm sorry to hear that you were nailed by a client for it... I'm lucky to be able to use the .drx in my workflow, which is to shoot 4.6k raw and then render to 4.6k prores before editing. But yes, the point of having prores in camera is to be able to shoot prores and I'm hoping to see that problem fixed (either now in 4.0 or soon in 4.x). RMA-ing the camera will not help because I'm fairly positive that it's a debayering issue in firmware.

Will get back to you later today.

Thanks Gary! I hope to clear some time today to do some testing as well. I hit submit on my post minutes before 4.0 dropped. Let's hope we get lucky and it's in there but not listed in the announcement.

OK, got the new 4.0 firmware installed and things seem to have improved with the crosshatching issue with one exception.

First, here's my testing methodology (empirical as it is). YMMV

1) For Prores, load file into Quicktime player. Turn looping on, start player and then scale player from very small to very large. Previously it would be simple to see the crosshatching pattern when you scaled through smaller multiples of the source resolution, such as 1/16, 1/8 and 1/4.

2) Then load file into your NLE of choice (in my case FCPX) and scale to various resolutions, zoom way in, play the file, etc. All empirical, but in previous firmware it was obvious to see a regular pattern when investigating this way.

First I wanted to see if the 4.6k on a 4.6k timeline crosshatching issue was fixed. Unfortunately it's not, but fortunately the drx workaround from BM USA (Veronica) still works. This first test is of Raw lossless 4.6k (full sensor) on a 4.6k timeline. Here's a zip file of the original sequence:

https://www.dropbox.com/s/xwr1nqenrfiv9p0/A002_08161324_C001%20Raw%20lossless%204point6k%20on%20a%204point6k%20timeline.zip?dl=0

Dropbox transcoded prores of the original sequence with no drx applied:

https://www.dropbox.com/s/wu4ak5yqy8wyilg/prores%204point6k%20on%204point6k%20timeline%20no%20drx%2001158780.mov?dl=0

Dropbox transcoded prores of the original sequence with the drx workaround applied:

https://www.dropbox.com/s/6ql9os8nwiv4fcp/prores%204point6k%20on%204point6k%20timeline%20with%20drx%2001158780.mov?dl=0

Screen capture of transcoded prores output of above file, rendered to 4.6k on 4.6k timeline WITHOUT the drx fix from BM USA and then viewed in the quicktime player and scaled down to a 1/8 multiple of the original file. I can clearly see the artifacts of the crosshatching here.

https://www.dropbox.com/s/y6y6p317hkypc9i/screenshot%204point6k%20on%204point6k%20timeline%20no%20drx%20-%20scaled%20in%20quicktime.jpg?dl=0

Screen capture of transcoded prores output of above file, rendered to 4.6k on 4.6k timeline WITH the drx fix from BM USA and then viewed in the quicktime player and scaled down to a 1/8 multiple of the original file. I cannot see any artifacts of the crosshatching here.

https://www.dropbox.com/s/8ut0y0d0wabql4z/screenshot%204point6k%20on%204point6k%20timeline%20with%20drx%20-%20scaled%20in%20quicktime.jpg?dl=0

Note that I get exactly the same results (with artifacts as above) if I shoot in the new Prores 4.6k format. Here's a copy of the Prores 4.6k files Straight Out Of Camera (SOOC):

https://www.dropbox.com/s/hngnlatzkb4x4cf/Prores%204point6k%20SOOC%20A002_08161326_C004.mov?dl=0

Load that into the Quicktime player (or any player) and scale it down to a smaller multiple and the crosshatching/screen artifact will appear.

----------------

The second test is of Prores422 UHD full sensor SOOC. This seems to be fixed!

Here's the file... You can load this and try rescaling it and you won't get the artifact.

https://www.dropbox.com/s/2189896i6nus1ei/Prores%20UHD%20SOOC%20A002_08161326_C005.mov?dl=0

Same thing with full sensor HD. Also no weirdness that I can see.

https://www.dropbox.com/s/eeg0m1jmdfeggfh/Prores%20HD%20SOOC%20A002_08161326_C006.mov?dl=0

I have not tried all the other new formats, nor have I tried windowed sensor. Will keep testing, but for now it looks like 4.6k on a 4.6k timeline is the main issue, and for me I'm ok with it using the drx workaround.

The biggest major bug I've seen is that if you're in the menus and initiate a recording without leaving menu mode, there'll be a few seconds of black-screen latency and then the recording will initiate. But the file will be corrupted. Either it needs to be fixed so that we can initiate recordings correctly without latency and corruption from menu mode, or we should be required to exit menu mode to start recording. I've posted a bug report about that one.

I'll keep testing, but I suggest that y'all do also and we'll compare notes.

I only experience this in Premiere Pro. With Firmware 4.0 I've experimented with 4.6K PRORES through HD. The crosshatching is subtle and not bad at UHD PRORES HQ, and I can work with the footage. However, as I go with a higher quality codec like PRORES 444 & 444 XQ in UHD or higher resolution the crosshatch becomes worse in PPro. However, if I make it full screen on my iMac 5K the crosshatch doesn't show up while playing the footage at all.

This is what I'll say about the issue in PPro: I need to figure out how to fix the debayer in PPro. I've looked through the preferences and have yet to find anything. Now, I work in Resolve these days as my main nonlinear. However, occasionally I go back to Premiere for specific projects. Also, now Frame.io has direct integration with PPro so that I can upload a sequence and bring back the comments as markers into the sequence. That's really nice for collaboration.

Anyone have any ideas how to fix Premiere's debayer? The way I see it it all has to do with the high resolution and high quality codec files.

timbutt2 wrote:I only experience this in Premiere Pro. With Firmware 4.0 I've experimented with 4.6K PRORES through HD. The crosshatching is subtle and not bad at UHD PRORES HQ, and I can work with the footage. However, as I go with a higher quality codec like PRORES 444 & 444 XQ in UHD or higher resolution the crosshatch becomes worse in PPro. However, if I make it full screen on my iMac 5K the crosshatch doesn't show up while playing the footage at all.

This is what I'll say about the issue in PPro: I need to figure out how to fix the debayer in PPro. I've looked through the preferences and have yet to find anything. Now, I work in Resolve these days as my main nonlinear. However, occasionally I go back to Premiere for specific projects. Also, now Frame.io has direct integration with PPro so that I can upload a sequence and bring back the comments as markers into the sequence. That's really nice for collaboration.

Anyone have any ideas how to fix Premiere's debayer? The way I see it it all has to do with the high resolution and high quality codec files.

This whole crosshatch thing seems to be camera issue. I have footage from a shoot we did where we shot footage of a conference using the UM46 and the BMPC4k. Both cameras were shooting UHD. The UM46 shows the crosshatch pattern and the BMPC4k does not. And it doesn't just show it in premiere or in resolve, it shows it when playing back in VLC player too. Also, the crosshatching seems to get worse when using higher ISOs. This is an annoying issue.

Phillip Bergman wrote:

timbutt2 wrote:I only experience this in Premiere Pro. With Firmware 4.0 I've experimented with 4.6K PRORES through HD. The crosshatching is subtle and not bad at UHD PRORES HQ, and I can work with the footage. However, as I go with a higher quality codec like PRORES 444 & 444 XQ in UHD or higher resolution the crosshatch becomes worse in PPro. However, if I make it full screen on my iMac 5K the crosshatch doesn't show up while playing the footage at all.

This is what I'll say about the issue in PPro: I need to figure out how to fix the debayer in PPro. I've looked through the preferences and have yet to find anything. Now, I work in Resolve these days as my main nonlinear. However, occasionally I go back to Premiere for specific projects. Also, now Frame.io has direct integration with PPro so that I can upload a sequence and bring back the comments as markers into the sequence. That's really nice for collaboration.

Anyone have any ideas how to fix Premiere's debayer? The way I see it it all has to do with the high resolution and high quality codec files.

This whole crosshatch thing seems to be camera issue. I have footage from a shoot we did where we shot footage of a conference using the UM46 and the BMPC4k. Both cameras were shooting UHD. The UM46 shows the crosshatch pattern and the BMPC4k does not. And it doesn't just show it in premiere or in resolve, it shows it when playing back in VLC player too. Also, the crosshatching seems to get worse when using higher ISOs. This is an annoying issue.

Okay, maybe I'm seeing something else. It's image scaling that I'm seeing. It's not a camera related issue. It's a scaling issue. I've had no issues with the footage other than the non-linear editing software.

timbutt2 wrote:

Phillip Bergman wrote:

timbutt2 wrote:I only experience this in Premiere Pro. With Firmware 4.0 I've experimented with 4.6K PRORES through HD. The crosshatching is subtle and not bad at UHD PRORES HQ, and I can work with the footage. However, as I go with a higher quality codec like PRORES 444 & 444 XQ in UHD or higher resolution the crosshatch becomes worse in PPro. However, if I make it full screen on my iMac 5K the crosshatch doesn't show up while playing the footage at all.

This is what I'll say about the issue in PPro: I need to figure out how to fix the debayer in PPro. I've looked through the preferences and have yet to find anything. Now, I work in Resolve these days as my main nonlinear. However, occasionally I go back to Premiere for specific projects. Also, now Frame.io has direct integration with PPro so that I can upload a sequence and bring back the comments as markers into the sequence. That's really nice for collaboration.

Anyone have any ideas how to fix Premiere's debayer? The way I see it it all has to do with the high resolution and high quality codec files.

This whole crosshatch thing seems to be camera issue. I have footage from a shoot we did where we shot footage of a conference using the UM46 and the BMPC4k. Both cameras were shooting UHD. The UM46 shows the crosshatch pattern and the BMPC4k does not. And it doesn't just show it in premiere or in resolve, it shows it when playing back in VLC player too. Also, the crosshatching seems to get worse when using higher ISOs. This is an annoying issue.

Okay, maybe I'm seeing something else. It's image scaling that I'm seeing. It's not a camera related issue. It's a scaling issue. I've had no issues with the footage other than the non-linear editing software.

Yea see this is what I'm seeing in simple playback of the footage on VLC. In the dark areas you can see that grid pattern. You'll need to save the image and up it up fully to be able to see the grids

And then here is another really bad grid pattern shooting at ISO 1600, 4.6k prores LT. This is rendered in premiere to 4.6k H265. And this is what it looks like when played back on Windows Media Player. Makes ISO 1600 pretty much useless. Again download the image and open it up fullscreen to see the awful grid pattern.

Phillip, which firmware are you using? I'm assuming firmware 4.0 because you're shooting 4.6k prores, correct?

It's very likely that the only way to shoot 4.6k and edit in a 4.6k timeline (either raw or prores) would be to apply the workaround .drx to the footage in Resolve first, then render to another 4.6k prores file that you'd then edit in premiere. If you do that, the footage will be usable. But it also appears that shooting UHD prores and editing in a UHD timeline is working with 4.0 (at least for full sensor readout... haven't tested windowed yet).

Phillip Bergman wrote:And then here is another really bad grid pattern shooting at ISO 1600, 4.6k prores LT. This is rendered in premiere to 4.6k H265. And this is what it looks like when played back on Windows Media Player. Makes ISO 1600 pretty much useless. Again download the image and open it up fullscreen to see the awful grid pattern.

In this case, for the shoot you referenced here, you must've been using firmware 3.3, correct? If so, the crosshatch issue was not addressed in that version of the firmware yet.

Phillip Bergman wrote:This whole crosshatch thing seems to be camera issue. I have footage from a shoot we did where we shot footage of a conference using the UM46 and the BMPC4k. Both cameras were shooting UHD. The UM46 shows the crosshatch pattern and the BMPC4k does not. And it doesn't just show it in premiere or in resolve, it shows it when playing back in VLC player too. Also, the crosshatching seems to get worse when using higher ISOs. This is an annoying issue.

I found the solution to my problem in PPro:

In both Source and Program Monitor you need to turn on High Quality Playback.

It's located under the Settings for each Monitor. This is the Wrench that is next to Playback Resolution Drop Down and the Timecode, on the lower right, just above the Monitor's timeline.

That solved it all. No more issues with the cross hatching that I was seeing in Premiere Pro.

This is similar to adjusting the debayer in Resolve.

POST EDIT: I was working with 4608x2592 PRORES 444 XQ footage to examine the problem.

Hi Gary,
If you haven't tried already in your project settings de-click enable video field processing in master project settings.
Let me know if that works?
Cheers


Glenn Hanns
DOP
Sydney, OZ

timbutt2 wrote:I found the solution to my problem in PPro:

In both Source and Program Monitor you need to turn on High Quality Playback.

It's located under the Settings for each Monitor. This is the Wrench that is next to Playback Resolution Drop Down and the Timecode, on the lower right, just above the Monitor's timeline.

That solved it all. No more issues with the cross hatching that I was seeing in Premiere Pro.

This is similar to adjusting the debayer in Resolve.

POST EDIT: I was working with 4608x2592 PRORES 444 XQ footage to examine the problem.

Yea this worked for me too....turning on high quality playback removes the crosshatch pattern...however I'm still curious as to why this pattern shows up when I just play the prores files on a player such as quicktime or VLC

Gary Yost wrote:In this case, for the shoot you referenced here, you must've been using firmware 3.3, correct? If so, the crosshatch issue was not addressed in that version of the firmware yet.

Phillip Bergman wrote:This whole crosshatch thing seems to be camera issue. I have footage from a shoot we did where we shot footage of a conference using the UM46 and the BMPC4k. Both cameras were shooting UHD. The UM46 shows the crosshatch pattern and the BMPC4k does not. And it doesn't just show it in premiere or in resolve, it shows it when playing back in VLC player too. Also, the crosshatching seems to get worse when using higher ISOs. This is an annoying issue.

Yea I still had 3.3 during that conference shoot. But updating to 4.0 hasn't really changed anything with the crosshatch pattern. It's always evident when shooting in low light at high ISO. And it's more evident the higher the resolution. I guess I'll just avoid shooting 800 or 1600 as much as I can. What is the .drx file that you have?

Phillip Bergman wrote:

timbutt2 wrote:I found the solution to my problem in PPro:

In both Source and Program Monitor you need to turn on High Quality Playback.

It's located under the Settings for each Monitor. This is the Wrench that is next to Playback Resolution Drop Down and the Timecode, on the lower right, just above the Monitor's timeline.

That solved it all. No more issues with the cross hatching that I was seeing in Premiere Pro.

This is similar to adjusting the debayer in Resolve.

POST EDIT: I was working with 4608x2592 PRORES 444 XQ footage to examine the problem.

Yea this worked for me too....turning on high quality playback removes the crosshatch pattern...however I'm still curious as to why this pattern shows up when I just play the prores files on a player such as quicktime or VLC

Did the render or export work fine though?

I did what you did above and that fixed the playback issue, but when exported that clip , the grid artifact was still in the render.

timbutt2 wrote:I found the solution to my problem in PPro:

In both Source and Program Monitor you need to turn on High Quality Playback.

It's located under the Settings for each Monitor. This is the Wrench that is next to Playback Resolution Drop Down and the Timecode, on the lower right, just above the Monitor's timeline.

That solved it all. No more issues with the cross hatching that I was seeing in Premiere Pro.

This is similar to adjusting the debayer in Resolve.

POST EDIT: I was working with 4608x2592 PRORES 444 XQ footage to examine the problem.

Does your renders have cross pattern still thought?

I turned the high quality playback on and that fixed the problem inside premier, while in playback and scrubbing. But once i rendered the footage, the export did have the cross hatch artifact in the render. Let me know if you have found any other workarounds. Because yes anything shot in 800 or 1600 slightly underexposed you can really see it , makes it unusable.

I have brought 3840 pro res files into a 1080 timeline, and that worked. But i would like to upload in 4k to vimeo or youtube.

Blaine, until this is truly resolved, you might get decent results if you upscale the good 1080p from the timeline to 4K UHD for upload. I think that would work well in Resolve, but I am not a Pr user.


Sent from my iPad using Tapatalk

Blaine Suque wrote:

timbutt2 wrote:I found the solution to my problem in PPro:

In both Source and Program Monitor you need to turn on High Quality Playback.

It's located under the Settings for each Monitor. This is the Wrench that is next to Playback Resolution Drop Down and the Timecode, on the lower right, just above the Monitor's timeline.

That solved it all. No more issues with the cross hatching that I was seeing in Premiere Pro.

This is similar to adjusting the debayer in Resolve.

POST EDIT: I was working with 4608x2592 PRORES 444 XQ footage to examine the problem.

Does your renders have cross pattern still thought?

I turned the high quality playback on and that fixed the problem inside premier, while in playback and scrubbing. But once i rendered the footage, the export did have the cross hatch artifact in the render. Let me know if you have found any other workarounds. Because yes anything shot in 800 or 1600 slightly underexposed you can really see it , makes it unusable.

I have brought 3840 pro res files into a 1080 timeline, and that worked. But i would like to upload in 4k to vimeo or youtube.

Give me a little to investigate this. I didn't export the test I did back then out because I was primarily looking for a solution to that preview browser issue. I generally do all my finishing in Resolve and don't deal with this issue inside Resolve.

Blaine, no I did not get any crosshatching on the exported file. I exported it out at 3840x2160 H.264 YouTube 4K settings with a few modifications such as checking Maximum Render Quality, upping the bit-rate, and doing 2-Pass. I'm not going to upload the file because it's a RAW shot with no trimming. Basically I did a slow-motion shot of water down some rocks, and after starting I went back to the beginning and started again. The camera work is rough and not polished. I was simply testing the clip. Export is fine, and that's all that matters.

I'm getting the exact same thing with UHD proresHQ after upgrading to 4.0
Looks like I'm rolling back to 3.1 for now until this is fixed.

As far as I can tell, the crosshatching occurs when you scale an image that is already suffering from the maze pattern effect, a debayering artifact. You can see it when you're zoomed in at 100% or more on a RAW file (or a sensor-sized ProRes file), most visible when underexposed.

According to https://sites.google.com/site/cornerfix ... patterns-1, this happens when the two green channels of the bayer pattern sensor aren't correctly balanced. Using CornerFix (with zeroed corner adjustment) to adjust the BayerGreenSplit parameter in a DNG file, I was able to convert my DNG with maze issues to one that was completely maze free. Unfortunately, DaVinci Resolve doesn't read the BayerGreenSplit parameter, so in DR there was no difference, only in other apps.

Years ago, the maze pattern effect was an issue in other apps too, like Lightroom. Maybe BMD is sticking with this debayering algorithm because it is a bit sharper. What I do is simply make sure I shoot with sensor coverage that is bigger than my final delivery. Resizing with a suitable algorithm mostly gets rid of the effect (or you end up with the crosshatching detailed in this thread). It's one of the reasons a 4.6K sensor is such a good thing (and maybe by design?).

Shot a quick anamorphic test 3k - prores HQ yesterday and looked at the footage through QT8 (See attached photo).
I then brought the footage into resolve and processed it quickly on an HD timeline. when rendered the footage the pattern vanished...

What if I give the footage directly to the client without processing it with resolve? I can't do that even though I am shooting PRORES!
This needs to be fixed!

I am not sure if I am doing something wrong or not.

I am running 4.0 BTW

I tried bringing the footage into FCPX to see if the pattern is there and it was more severe

I'm only working in Resolve, no roundtripping. Nothing fancy then of course. When I had that 'screen door' effect, it was during the Edit and Colour pages, but when I rendered in Deliver with highest quality debayer, it was clean.


Sent from my iPad using Tapatalk

Even if RED is using pretty strong anti-aliasing filters (OLPF), I've seen similar artifacts in very early incarnations of their debayering algorithms. Remember, it took them years to get it to the quality it has today. The nice thing is: even footage from our first RED One (wich is long gone in exchange for a newer model) is looking better now than in it's early days. So, relax, it can be fixed in software.

Getting debayering right is complex science, it's the "coke recipe" of camera makers. You need to target a very difficult balance between resolution and artefacting. Arri had massive support from Fraunhofer Institut, a very respected scientific organization in Germany, to get theirs right.

So, give BM some time to sort that out. And John is perfectly right on the issue of oversampling. You'll never get true 4.6K resolution from 4.6 megapixels. The best algorithms get up to 75 or maybe 80% out of a Bayer-pattern CMOS sensor!

Uli.. true words...

But don't you think it looks a lot like something that could be solved with BayerGreenSplit normally?
(only problem that resolve doesn't care for that dng attribute anyways)

I have noticed that all my footage prior to the 3.3 update doesn't show any signs of the Crosshatch pattern. But all my footage since 3.3 and 4.0 now has it, and it's horrible. Like someone else mentioned, there's no way I could ever give raw footage to a client with this cross hatching going on. I've owned a Blackmagic Cinema camera and a Production camera and neither of those cameras showed this type of problem, so why is it such a difficult thing to fix now? It's truly annoying to have spent so much money to "upgrade" to a better camera that has problems that 3-4 year old camera from the same company didn't have. It's just frustrating and makes me question my choice of picking this camera over the RED Raven. But I'm stuck with this camera now and just have to hope that BMD fixes these issues in the final release of 4.0 (whenever that may be).

Hi! Found this thread because I was having this exact same issue and I was getting nowhere but a headache from trying to decipher what everyone was saying. Anyway I downloaded the latest Resolve version 12.5.3 and when I opened it up my project seemed to be fixed! Thought that might help anyone else if they stumble onto it! I was having the same issue where if I filmed in RAW 4.6K and changed the timeline to be 4.6K instead of UHD I would get this crosshatching pattern. I think it took me so long to see because I rarely worked in 4.6K, but needed it for a few projects in order to do some crops which I wanted to handle in Premiere.

Be sure to check your final renders out of Premiere carefully. Depending on your workflow and intended distribution format, the issue can show up in rendered files even if you didn't see it in your editing or grading application GUI.

Yup, check your footage (in your NLE) at something like 200% or 400%, I'm pretty sure you'll still see the grid.

You'll see it as well in your exports if they are high quality, but it can disappear depending on your compression settings.

Also, maybe it's gone now because Resolve changed its scaling algorithm with the update, but it's still there in the original footage.

This issue is camera-related, if you had it, chances are you still have it :/ Sorry !

Jamie LeJeune wrote:Be sure to check your final renders out of Premiere carefully. Depending on your workflow and intended distribution format, the issue can show up in rendered files even if you didn't see it in your editing or grading application GUI.

Ugh, you're right Jamie I can still see it in my final version! The deliverable file is HD and you can't see it there, but still upsetting that I can't get a high quality master! I noticed in Premiere that when I pause the lines go away and only seem to show up when I'm playing it back. Back to the drawing board I guess