"screen-door" crosshatching on Ursa Mini 4.6k images

The place for questions about shooting with Blackmagic Cameras.
  • Author
  • Message
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

"screen-door" crosshatching on Ursa Mini 4.6k images

PostThu Jul 21, 2016 2:42 am

Ran into an issue looking at some enlargements of the image on a 4:1 compressed RAW shoot I did yesterday that show a regular cross-hatched pattern on the entire image. Does not appear to be FPN, it's something else.

Here's a dropbox link to the enlargement (jpg): https://www.dropbox.com/s/lfnit698z2ddkol/46k%20crosshatch%20enlargement.jpg?dl=0 (show it in full-screen on dropbox)

And a link to the full-size image (jpg): https://www.dropbox.com/s/lfnit698z2ddkol/46k%20crosshatch%20enlargement.jpg?dl=0

I can't seem to post multiple image attachments here, so this is a link to my post on BMC User.

http://www.bmcuser.com/showthread.php?17943-Cross-hatch-pattern-on-Ursa-Mini-4k-image&p=216405#post216405

And here's a dropbox link to the 4:1 compressed dng. If you zoom way in, you'll see it. It looks this way no matter what scaling option is used in Resolve (Smoother, Sharper, Bilinear). Is this an artifact of 4:1 compression on the UM4.6k or is it something else?

https://www.dropbox.com/s/oeua7w3438cl1za/Blackmagic%20URSA%20Mini_2016-07-19_1557_C0000_007796.dng?dl=0

Note that I sent this off to a friend, he brought it into Resolve and (in Rec709 profile) saved it as a tiff and when viewing this at high magnification we don't see the crosshatching, just normal pixels. Here's a link to that:

https://www.dropbox.com/s/3suh9hf0vn1fube/Untitled00086513.tif?dl=0

Anyone have any idea what's going on here?
Offline
User avatar

rick.lang

  • Posts: 8994
  • Joined: Wed Aug 22, 2012 5:41 pm
  • Location: Victoria BC Canada

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostThu Jul 21, 2016 3:20 am

A scaling artifact that will not Woodard in rendered deliverables. A few other posts on this recently. I was taken aback when I first saw this in some of my footage in Resolve, but nothing to worry about after all.


Sent from my iPad using Tapatalk
Rick Lang
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re:

PostThu Jul 21, 2016 4:06 am

rick.lang wrote:A scaling artifact that will not Woodard in rendered deliverables. A few other posts on this recently. I was taken aback when I first saw this in some of my footage in Resolve, but nothing to worry about after all.


Rick, I'm aware of the debayering/scaling artifacts, but check out the post in the BMC User forum... it includes a link to the rendered deliverables, which also show the pattern. I'll dig into it more in the morning.
Offline
User avatar

Tom

  • Posts: 1626
  • Joined: Wed Aug 22, 2012 5:08 am
  • Location: Manchester, UK

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostThu Jul 21, 2016 9:35 am

Go into your project settings:


Select "image scaling"

Change the Resize filter from Bilinear to optimize for playback



On Bilinear I see the effect - on the others, I dont.
Tom Majerski
http://tetragrade.com/
http://www.imdb.com/name/nm5157752/
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostThu Jul 21, 2016 1:48 pm

Tom wrote:Go into your project settings:
Select "image scaling"
Change the Resize filter from Bilinear to optimize for playback
On Bilinear I see the effect - on the others, I dont.


Thanks Tom, but I always have been using Optimize-for-playback. I see the effect in Bilinear all the time, and O-f-p when I'm playing (but not when stopped on an image), and I don't see it in Sharper or Smoother.

I didn't think that this was a problem until a friend zoomed into my final rendered output and showed it to me there.

I'm familiar with the Bilinear screen door effect and never use it.... always use Optimize-for-playback. What's weird is that this pattern is making its way through debayering all the way to output. Here's a dropbox link to a tiff file of one frame. If you zoom into 6-800% it becomes super obvious.

[url]https://www.dropbox.com/s/c4s5l4zx06u7ptb/crosshatch%20-%20log_1.1.1.tif?dl=0"]https://www.dropbox.com/s/c4s5l4zx06u7ptb/crosshatch%20-%20log_1.1.1.tif?dl=0[/url]

Here's a screenshot of it in Resolve, with Optimize-for-playback scaling selected:

[url]https://www.dropbox.com/s/fygue6mo4gcgh5c/crosshatch%20resolve%20screenshot.png?dl=0"]https://www.dropbox.com/s/fygue6mo4gcgh5c/crosshatch%20resolve%20screenshot.png?dl=0[/url]

And here's a screenshot of what it looks like in FCPX at 600%:

[url]https://www.dropbox.com/s/1wiq0i98y4rt76g/cross-hatch%20in%20FCPX%20log.png?dl=0"]https://www.dropbox.com/s/1wiq0i98y4rt76g/cross-hatch%20in%20FCPX%20log.png?dl=0[/url]

Finally here's a 10-second clip in ProresLT format of the log file. Load it into any NLE and zoom to 600%.

[url]https://www.dropbox.com/s/s7kfunn96l6d8yn/crosshatch%2010%20second%20clip.mov?dl=0"]https://www.dropbox.com/s/s7kfunn96l6d8yn/crosshatch%2010%20second%20clip.mov?dl=0[/url]

I need to contact US support today about it. The Captain's notified them of incoming.
Offline
User avatar

Tom

  • Posts: 1626
  • Joined: Wed Aug 22, 2012 5:08 am
  • Location: Manchester, UK

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostThu Jul 21, 2016 1:52 pm

Tom Majerski
http://tetragrade.com/
http://www.imdb.com/name/nm5157752/
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostThu Jul 21, 2016 2:17 pm

Offline
User avatar

rick.lang

  • Posts: 8994
  • Joined: Wed Aug 22, 2012 5:41 pm
  • Location: Victoria BC Canada

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostThu Jul 21, 2016 4:18 pm

Gary, sorry about that. I hadn't read the later posts on the other thread. Tom, thanks for those tips on settings.


Sent from my iPad using Tapatalk
Rick Lang
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostThu Jul 21, 2016 4:42 pm

With more experimentation, I have more insight into what's going on. My workflow for this video is to shoot in raw only for the added resolution benefit of 4.6k, so after shooting, I import the media and set my project resolution to Custom 4608x2592. THAT seems to be the problem. If my project res is set to 4.6k, and when I deliver at that resolution, I see the cross-hatching in both the UI and the rendered output.

But if the project res is set to 4096 full aperture and if I select Render to Source Resolution, I do NOT get the cross-hatching effect in the UI but I DO get it in the rendered output.

And if the project res is set to 4096 and if Render to Source Resolution is NOT selected, the cross-hatching is gone in both UI and rendered output.

So it's definitely not a camera problem, but the issue here is that my workflow in many cases is to shoot in raw 4.6k and then transcode everything to prores 4444 or 422HQ for editing and then final grading. I do that for the extra resolution and flexibility for white balance, highlight recovery, etc.

And of course shooting at 4608x2592 and outputting at 4096x3112 is an entirely different aspect ratio.

So, more insight and hopefully this is either "just" a resolve bug or one of my other settings that's causing the problem. WEIRD.
Offline

Sebastian Kaz

  • Posts: 161
  • Joined: Wed May 28, 2014 2:17 pm
  • Location: Newcastle, Australia

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 2:12 am

I had the exact same thing happen, it's all scaling issues.
I rendered out 4.6k ProRes and played it back on a Thunderbolt Display (2560x1440) in QuickTime and I had the crosshatching effect all through the footage.
I re-rendered it out at screen native and at 1080p and the issue was gone.
It appears it's how the system downscales the footage to the screen.
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 2:23 am

Sebastian Kaz wrote:I had the exact same thing happen, it's all scaling issues.
I rendered out 4.6k ProRes and played it back on a Thunderbolt Display (2560x1440) in QuickTime and I had the crosshatching effect all through the footage.
I re-rendered it out at screen native and at 1080p and the issue was gone.
It appears it's how the system downscales the footage to the screen.


Yup, it's all in the way the image is being scaled. Here's an update... today Blackmagic support has acknowledged to me that this is a bug. If you plug 4608x2592 into the Timeline resolution field, and if you're using raw files (I know 4:1 compressed will do it but I haven't tried uncompressed or 3:1 yet), it will exhibit the crosshatching pattern. If you use any of the supplied presets for Timeline resolution this will not happen... only when you use the 4.6k resolution numbers. For example if your timeline is set to UHD you'll never see this.

Blackmagic does have a workaround for it internally that addresses the problem to some extent, but not in a very satisfying way. (If you're interested in their workaround you'll have to contact them directly.) I will continue to talk with them to discover more about the issue, and hope that they'll have a real fix for it soon.
Offline
User avatar

Tom

  • Posts: 1626
  • Joined: Wed Aug 22, 2012 5:08 am
  • Location: Manchester, UK

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 9:31 am

this fix will work, and is very easy to do:

http://tommajerski.com/publicimages/Scr ... 010.29.jpg

Image


change the input sizing by moving the pan and tilt by 0.5
Tom Majerski
http://tetragrade.com/
http://www.imdb.com/name/nm5157752/
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 1:01 pm

Tom, you're absolutely right. Changing input sizing Pan/Tilt to .5 is not the "fix" I received, but IMHO the temporary solution I was provided yesterday (with the request that I not pass it along to anyone) produces a similar but not quite as effective change as simply setting input sizing P/T to 0.5. Here's a comparison, all files on dropbox:

Here's the original problem... a 4.6k (4608x2592) file in a 4608x2592 timeline.

https://www.dropbox.com/s/zdqqcmjm1b5lytj/full%20res%20crosshatch%20bm%20fix%20off.png?dl=0

Here it is with the "fix" I received. You can see in the red-circled area that the pattern is greatly mitigated, but at the expense of some sharpness (and the pattern is clearly still there).

https://www.dropbox.com/s/pxju7tjhz1ey1e6/full%20res%20crosshatch%20bm%20fix%20on.png?dl=0

Here's what it looks like with the input sizing Pan/Tilt set to 0.5.

https://www.dropbox.com/s/qy7h1c59nnm4ykc/input%20sizing%20fix.png?dl=0

Finally, here's what it looks like when the Timeline resolution is set to any preset (in this case 4096x3112 full aperture):

https://www.dropbox.com/s/a60enxbv25svghx/4096x3112%20full%20aperture%20fix%20off.png?dl=0

IMHO changing input sizing P/T to 0.5 is a much better "fix" for the problem than what I was provided by BM yesterday. I'll use that method until a new version of Resolve is released that addresses the problem.

Thanks for the help digging into this, Tom.

What I don't understand is why there isn't a 4608x2592 Timeline resolution preset, because I'd imagine that a common workflow would be to bring raw files into the system and output them in full 4.6k resolution as bmdfilm/prores422HQ or 4444 for editing in another NLE (in my case fcpx)... using those prores files throughout the entire rest of the process, editing/grading/finishing. I love this workflow because I get the advantages of the extra resolution and ability to tweak the raw settings in post, but also being able to edit in fcpx with a relatively lightweight format. (As much as I'd love to edit in Resolve -- and I've spent weeks getting up to speed on it with AlexisVH's excellent tutorials -- the Resolve keywording/logging functions are nowhere near what I can do in fcpx and keywording/logging is at the core of my editing process.)
Offline
User avatar

Tom

  • Posts: 1626
  • Joined: Wed Aug 22, 2012 5:08 am
  • Location: Manchester, UK

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 1:16 pm

No Problem Gary,

Glad you have some options for a temporary solution.


Generally I have not graded in a 4.6k timeline as any NR or sharpening levels look better when applied to the intended max delivery resolution, so I would usually grade on a 4K DCI or UHD timeline.

I expect this will be fixed at some point though.

Good to just get to the bottom of it :-)
Tom Majerski
http://tetragrade.com/
http://www.imdb.com/name/nm5157752/
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 2:07 pm

Tom wrote:Generally I have not graded in a 4.6k timeline as any NR or sharpening levels look better when applied to the intended max delivery resolution, so I would usually grade on a 4K DCI or UHD timeline.


I don't grade on a 4.6k timeline either... after I bring the 4.6k prores files into FCPX everything lives in the final delivery timeline, either HD, UHD or 4KDCI. It's in one of those formats when I round-trip back to Resolve for grading. I just need the 4.6k footage for that extra bit of resolution for stabilization, punch-ins, pushes, etc.

And thanks again!
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 3:08 pm

OK, continuing to do tests here and am finding out other disturbing issues. This new test is of Prores 444XQ UHD 23.98 full sensor readout, BMDfilm.

Here's what the file looks like when brought into a UHD timeline in FCPX. The same cross-hatching that I've been seeing in the raw files in the previous tests.

https://www.dropbox.com/s/7e4389j45qcc3no/FCPX%20UHD%20timeline.png?dl=0

Now here's what happens in FCPX when you drop the timeline resolution to HD:

https://www.dropbox.com/s/32xz9wr933djjzv/FCPX%20HD%20timeline.png?dl=0

And I'm seeing the same thing in Resolve. Here's what the UHD file looks like on a UHD timeline:

https://www.dropbox.com/s/82s4rdo3roeacy7/UHD%20timeline%20Pan-Tilt%20at%200.png?dl=0

Here's what it looks like on a UHD timeline with Pan/Tilt at 0.5. This mitigates the problem slightly but does not anywhere near eliminate it, and at the cost of image sharpness (note that the "workaround/fix" BM gave me yesterday doesn't affect this image at all):

https://www.dropbox.com/s/255zjmkdylwzqj0/UHD%20timeline%20Pan-Tilt%20at%2005.png?dl=0

And here's what it looks like in Resolve on an HD timeline.

https://www.dropbox.com/s/py7upprc3z7cb ... 0.png?dl=0

You can see that exactly the same thing is happening with this Prores file as with the previous Raw file, but in this case it was shot in Prores at UHD resolution vs the Raw file which was shot at 4.6k. What seems to be happening is that this cross-hatching is appearing on the image WHEN THE TIMELINE IS SET TO THE SAME RESOLUTION AS THE IMAGE. When you switch the timeline resolution from the original image spec to any other spec, cross-hatching goes away.

I'm wondering if there's a slim possibility that it might be a sensor problem and that it's simply disappearing when the timeline resolution (in either FCPX or Resolve) is set to another value than the input, which forces the NLE/Resolve to rescale the image, hiding the cross-hatching pattern. Could be, but my hunch is still that it's in the debayer code.

FYI, here's the original Prores444XQ file if you want to look at it yourself. Only 2 seconds, reasonable download.

https://www.dropbox.com/s/90iuz571h7jx7q6/UM%20prores444XQ%202398.mov?dl=0

Anyone have any insight to this?
Last edited by Gary Yost on Fri Jul 22, 2016 5:54 pm, edited 1 time in total.
Offline

Mike Halper

  • Posts: 286
  • Joined: Sun Feb 03, 2013 10:50 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 4:54 pm

If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.
IMac Pro Hackintosh, 10 core i9, 64GB RAM, EVGA Nvidia 1080TI FTW3 Gaming, Decklink 4K Mini Monitor, macOS 10.13.6, DaVinci Resolve Studio license
Offline
User avatar

Tom

  • Posts: 1626
  • Joined: Wed Aug 22, 2012 5:08 am
  • Location: Manchester, UK

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 5:41 pm

Mike Halper wrote:If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.



There is zero indication that this is a "sensor issue". If anything, the fact that changes to how its debayered correct it point towards it being a debaying issue. Which can be fixed by fw updates and changes to resolve.

Let's not start spreading claims of hardware faults before we have all the facts.
Tom Majerski
http://tetragrade.com/
http://www.imdb.com/name/nm5157752/
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 5:53 pm

Tom wrote:
Mike Halper wrote:If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.


There is zero indication that this is a "sensor issue". If anything, the fact that changes to how its debayered correct it point towards it being a debaying issue. Which can be fixed by fw updates and changes to resolve.

Let's not start spreading claims of hardware faults before we have all the facts.


I agree that it would be very very strange for this to be a sensor issue, and it really feels like a scaling issue to me. It does seem that it points to a problem with debarring. I've been speaking with the folks in customer service and they don't want to RMA the camera because they're feeling like it's in Resolve also.
Offline

Vincent Crafton

  • Posts: 2
  • Joined: Fri Jul 22, 2016 9:04 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 9:38 pm

Mike Halper wrote:If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.


I can vouch for the pattern's presence outside of Resolve as well. I can see it in Quicktime player and in Premiere, except in Premiere it can only be seen during playback, while paused the pattern disappears.

I've done limited testing, but found that (as warned) the detail setting in camera will exacerbate the problem.

After experimentation i've found that the problem exists most in Resolve when dropping uhd footage into a native uhd timeline. If uhd footage is dropped into an hd timeline, the problem disappears for the most part. Thus, my current workaround has been to create a timeline resolution that splits the difference between uhd and hd (2880x1620, this reduces the crosshatching effect), apply very light noise reduction and then render back out at uhd if needed. This of course knocks sharpness off but the footage looks 90% imo.

As the footage, can at times in Premiere, look pristine when paused, I'm inclined to believe that the root of the problem is in soft or firmware and not the sensor.

Can it be confirmed that this problem is present on AMD and NVIDIA rigs alike??? I'm on r9 fury w/ latest certified crimson drivers.
Offline

Mike Halper

  • Posts: 286
  • Joined: Sun Feb 03, 2013 10:50 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 10:20 pm

Tom wrote:
Mike Halper wrote:If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.



There is zero indication that this is a "sensor issue". If anything, the fact that changes to how its debayered correct it point towards it being a debaying issue. Which can be fixed by fw updates and changes to resolve.

Let's not start spreading claims of hardware faults before we have all the facts.


Then it's an internal debayering issue, which is still sensor-related. The ProRes 4444 XQ file is straight from camera, so either way it's a serious camera issue... again.
IMac Pro Hackintosh, 10 core i9, 64GB RAM, EVGA Nvidia 1080TI FTW3 Gaming, Decklink 4K Mini Monitor, macOS 10.13.6, DaVinci Resolve Studio license
Offline

Mike Halper

  • Posts: 286
  • Joined: Sun Feb 03, 2013 10:50 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 10:20 pm

Gary Yost wrote:
Tom wrote:
Mike Halper wrote:If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.


There is zero indication that this is a "sensor issue". If anything, the fact that changes to how its debayered correct it point towards it being a debaying issue. Which can be fixed by fw updates and changes to resolve.

Let's not start spreading claims of hardware faults before we have all the facts.


I agree that it would be very very strange for this to be a sensor issue, and it really feels like a scaling issue to me. It does seem that it points to a problem with debarring. I've been speaking with the folks in customer service and they don't want to RMA the camera because they're feeling like it's in Resolve also.


Can't be Resolve if the ProRes 4444 XQ file is straight from camera and never went to Resolve first.
IMac Pro Hackintosh, 10 core i9, 64GB RAM, EVGA Nvidia 1080TI FTW3 Gaming, Decklink 4K Mini Monitor, macOS 10.13.6, DaVinci Resolve Studio license
Offline

Mike Halper

  • Posts: 286
  • Joined: Sun Feb 03, 2013 10:50 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 10:25 pm

Vincent Crafton wrote:
Mike Halper wrote:If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.


I can vouch for the pattern's presence outside of Resolve as well. I can see it in Quicktime player and in Premiere, except in Premiere it can only be seen during playback, while paused the pattern disappears.

I've done limited testing, but found that (as warned) the detail setting in camera will exacerbate the problem.

After experimentation i've found that the problem exists most in Resolve when dropping uhd footage into a native uhd timeline. If uhd footage is dropped into an hd timeline, the problem disappears for the most part. Thus, my current workaround has been to create a timeline resolution that splits the difference between uhd and hd (2880x1620, this reduces the crosshatching effect), apply very light noise reduction and then render back out at uhd if needed. This of course knocks sharpness off but the footage looks 90% imo.


No one should have to downrez and then uprez footage to make it usable. The idea given previously of offsetting the frame by 0.5 pixels isn't a good solution either, which could create other issues since you now also need to scale the clip to properly fill the frame of the project.
IMac Pro Hackintosh, 10 core i9, 64GB RAM, EVGA Nvidia 1080TI FTW3 Gaming, Decklink 4K Mini Monitor, macOS 10.13.6, DaVinci Resolve Studio license
Offline

John Brawley

  • Posts: 1941
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Chicago Illinois

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 10:28 pm

Vincent Crafton wrote:
Mike Halper wrote:If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.


I can vouch for the pattern's presence outside of Resolve as well. I can see it in Quicktime player and in Premiere, except in Premiere it can only be seen during playback, while paused the pattern disappears.



This still then could be a display scaling issue.

Are you seeing it when you playback 1:1 when you play it in QT player ? Does it's severity change as you drag the window smaller or bigger ?

Do you see it on a TV when you render it out and play it on an actual television ?

By the way, if it's actually a debayer issue, then it's nothing to do with the sensor because the debayer step happens way down the path post sensor and we'd also expect different debayer steps to yield different results. How do these frames look in PS for example or C1 ? The in-camera Debayer algorithm is the same one that's used in Resolve though.

JB
John Brawley
Cinematographer
Atlanta
Georgia
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostFri Jul 22, 2016 11:10 pm

I agree that it's most likely a debayer issue in both the camera/prores and resolve/raw. I received a new workaround/fix today from Blackmagic and this one seems to do a pretty good job in 4.6k. They sent me versions for UHD and HD and although I've tested the UHD version, that doesn't seem to work -- I haven't tested the HD version yet so can't comment. Here are examples:

This is a tight crop of the 4.6k raw image straight out of camera. Obvious cross-hatching artifacts.

https://www.dropbox.com/s/7v0bq2m5nhs54n7/4608x2592%20raw%20no%20fix.png?dl=0

Here's the same with the fix applied. (The fix is in the form of a .drx file they sent me that must be applied to the first node in the graph. I have been asked not to redistribute it because they're still working on it.)

https://www.dropbox.com/s/tj4j78hzgko3mjl/4608x2592%20raw%20with%20fix.png?dl=0

And here's the same file in a 4096x3112 full aperture timeline.... looks very close to the 4.6k version with the fix applied.

https://www.dropbox.com/s/78u9z9tc5sp89lr/4096x3112%20full%20aperture%20no%20fix.png?dl=0

To me this feels like progress and my understanding is that engineering is taking the issue very seriously and that they do not consider it to be a sensor issue... that it's a firmware/resolve issue only.
Offline

Vincent Crafton

  • Posts: 2
  • Joined: Fri Jul 22, 2016 9:04 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 12:05 am

John Brawley wrote:
Vincent Crafton wrote:
Mike Halper wrote:If I open that ProRes 4444 XQ shot in Quicktime Player 7 and zoom in I can see the crosshatch. Looks to be a sensor issue. Curious if it's on all 4.6Ks.


I can vouch for the pattern's presence outside of Resolve as well. I can see it in Quicktime player and in Premiere, except in Premiere it can only be seen during playback, while paused the pattern disappears.



This still then could be a display scaling issue.

Are you seeing it when you playback 1:1 when you play it in QT player ? Does it's severity change as you drag the window smaller or bigger ?

Do you see it on a TV when you render it out and play it on an actual television ?

By the way, if it's actually a debayer issue, then it's nothing to do with the sensor because the debayer step happens way down the path post sensor and we'd also expect different debayer steps to yield different results. How do these frames look in PS for example or C1 ? The in-camera Debayer algorithm is the same one that's used in Resolve though.

JB


Yeah the pattern is still there at 1:1 in QT except it takes a different form, more finer...akin to regular noise...but a grid like pattern is still apparent. Indeed its rendition varies with resolution, so there is definitely a scaling component to the problem. Even taking a screen cap and scaling in and out in PS it renders differently...weird. The question is where the problem is exactly... in the original clip data, a codec, display driver or combination of such?

As I mentioned previously, after some cursory tests I have found that engaging the detail option in camera will make the problem worse (i.e. at max detail the clip will display a heavy crosshatch effect in Resolve, with detail turned off the effect is much more subdued). Being a neophyte when it comes to visual signals processing and encoding, I wish i could add more input.
Offline

Mike Halper

  • Posts: 286
  • Joined: Sun Feb 03, 2013 10:50 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 12:18 am

Is the streaking on the collar supposed to be there?
IMac Pro Hackintosh, 10 core i9, 64GB RAM, EVGA Nvidia 1080TI FTW3 Gaming, Decklink 4K Mini Monitor, macOS 10.13.6, DaVinci Resolve Studio license
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 1:05 am

Mike Halper wrote:Is the streaking on the collar supposed to be there?


Yes, that's denim material.... you're looking at the weave.
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 5:32 pm

Some additional tests, this time with ProResHQ files straight out of the camera.

1) Blackmagic URSA Mini_2016-07-23_0952_C0001_ProResHQ_UHD

https://www.dropbox.com/s/bnlgkteq3j17ch0/Blackmagic%20URSA%20Mini_2016-07-23_0952_C0001_ProResHQ_UHD.mov?dl=0

UHD full sensor readout. Put it into a UHD timeline and you'll see the artifact when you zoom way in. Note that I don't have a workaround from BM for this mode yet although the 4.6k .drx workaround they gave me does work on 4.6k Raw files, but not ProRes UHD.

BTW, if you view this in the Quicktime player and dynamically rescale the Quicktime window while playing, it's easy to see how the cross-hatching artifacts produces the screen-door effect as you scale through "harmonic multiples" of the artifact itself.


2) Blackmagic URSA Mini_2016-07-23_0953_C0003_ProResHQ_HD

https://www.dropbox.com/s/cjni5z8psepxqhl/Blackmagic%20URSA%20Mini_2016-07-23_0953_C0003_ProResHQ_HD.mov?dl=0

HD full sensor readout. When I put it into an HD timeline I don't see the cross-hatching at all, even at 1000%. Sure I see pixels of course, but not the cross-hatching artifact.

When I view this in the Quicktime player and dynamically rescale the Quicktime window while playing, I do NOT see the cross-hatching artifacts that can produce the screen-door effect while scaling through "harmonic multiples" of the artifact itself.


3) Blackmagic URSA Mini_2016-07-23_0954_C0006_ProResHQ_HD_windowed

https://www.dropbox.com/s/kwhfww0d5xdzeta/Blackmagic%20URSA%20Mini_2016-07-23_0954_C0006_ProResHQ_HD_windowed.mov?dl=0

HD windowed. Holy macaroni (!) -- the artifacting is really really bad here. I do not have any sort of workaround/fix from BM for this mode yet either.

Onward....
Offline

John Brawley

  • Posts: 1941
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Chicago Illinois

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 5:45 pm

Hi Gary.

If it's changing as you scale that strongly suggests a display scaling issue to me.

I went through something similar on the F55. Here s Avery long thread about it on the Sony forum.

http://community.sony.com/t5/F5-F55/F55 ... d-p/201051

And the same thing apparently with the FS5

https://community.sony.com/t5/F5-F55/St ... d-p/257361

Also the pocket cinema camera went through something similar here if you search the forums.

The real test as to if you have something baked in is to view 1:1 or view the rendered output of the file on a television.

I've yet to see anyone creat or have that pattern in those circumstances with the F55 or when the pocket issue was happening. I'm going to assume the same thing here, but perhaps it's worth checking that for yourself.

JB
John Brawley
Cinematographer
Atlanta
Georgia
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 6:25 pm

John, I apologize for not having been more clear in my post. My comment about viewing the _secondary_ effect of the debayer bug in the Quicktime viewer is not really germane to the discussion. It just speaks to the fact that the underlying bug in the debayer code manifests itself in multiple ways.

The problem is obvious when viewed 1:1 in 4.6k mode on a 4.6k timeline, in UHD on a UHD timeline, and in HD windowed mode on an HD timeline.

And as I mentioned, the folks at Blackmagic US are aware of the bug... aware to the point that they've given me a .drx file that, when applied to the first node of a 4.6k clip on a 4.6k timeline, fixes the problem, at least to such an extent that I cannot see the artifact anymore. I do not have .drx files that work in UHD and HD/windowed mode yet, but I'm confident that they'll figure this out and that the engineering team in Australia will come up with a firmware and Resolve fix that deals with it.

For now though, since my workflow is to shoot in 4.6k raw and then transcode to 4.6k prores after ingest, I'm good. If anyone else is dealing with this issue and wants access to the same workaround I'm using, I suggest contacting BM support directly.

John Brawley wrote:Hi Gary.

If it's changing as you scale that strongly suggests a display scaling issue to me.

I went through something similar on the F55. Here s Avery long thread about it on the Sony forum.

http://community.sony.com/t5/F5-F55/F55 ... d-p/201051

And the same thing apparently with the FS5

https://community.sony.com/t5/F5-F55/St ... d-p/257361

Also the pocket cinema camera went through something similar here if you search the forums.

The real test as to if you have something baked in is to view 1:1 or view the rendered output of the file on a television.

I've yet to see anyone creat or have that pattern in those circumstances with the F55 or when the pocket issue was happening. I'm going to assume the same thing here, but perhaps it's worth checking that for yourself.

JB
Offline

John Brawley

  • Posts: 1941
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Chicago Illinois

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 6:57 pm

Gary Yost wrote:John, I apologize for not having been more clear in my post. My comment about viewing the _secondary_ effect of the debayer bug in the Quicktime viewer is not really germane to the discussion. It just speaks to the fact that the underlying bug in the debayer code manifests itself in multiple ways.


I'm sorry for being specific, but there's reports of different behavior in different playback environments across different OS's.

So 1:1 in QT player you see it ?

So when watching a rendered output (not resolve monitor output) on a 1920 TELEVISION and not a computer monitor you see it ?

Because Resolve and most editing platforms like FCP do quick and dirty renderings for playback in RAW and for ProRes (or whatever) which is why you differences in playback and still images, also reported elsewhere in this thread.

JB
John Brawley
Cinematographer
Atlanta
Georgia
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 7:29 pm

Specificity is super important, no problem at all. Yes absolutely this issue is incredibly obvious in HD1920 on a standard television. I check my work on a 65" Sony LCD, which is quite unforgivingly clean and shows everything as plain as day.

John Brawley wrote:
Gary Yost wrote:John, I apologize for not having been more clear in my post. My comment about viewing the _secondary_ effect of the debayer bug in the Quicktime viewer is not really germane to the discussion. It just speaks to the fact that the underlying bug in the debayer code manifests itself in multiple ways.


I'm sorry for being specific, but there's reports of different behavior in different playback environments across different OS's.

So 1:1 in QT player you see it ?

So when watching a rendered output (not resolve monitor output) on a 1920 TELEVISION and not a computer monitor you see it ?

Because Resolve and most editing platforms like FCP do quick and dirty renderings for playback in RAW and for ProRes (or whatever) which is why you differences in playback and still images, also reported elsewhere in this thread.

JB
Offline

John Brawley

  • Posts: 1941
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Chicago Illinois

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 7:49 pm

Gary Yost wrote:Specificity is super important, no problem at all. Yes absolutely this issue is incredibly obvious in HD1920 on a standard television. I check my work on a 65" Sony LCD, which is quite unforgivingly clean and shows everything as plain as day.


And how are you feeding the monitor ? What is the playback source ?

JB
John Brawley
Cinematographer
Atlanta
Georgia
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 7:57 pm

John Brawley wrote:And how are you feeding the monitor ? What is the playback source ?

JB


I feed it either directly from iTunes or from Vimeo via Apple TV. Either of these will display the issue.

And as I said before, the folks at Blackmagic US Support have already acknowledged the problem, they have a workaround for 4.6k raw clips in a 4.6k timeline condition, and I'm confident that they'll "resolve" it.
Offline

John Brawley

  • Posts: 1941
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Chicago Illinois

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 8:02 pm

Gary Yost wrote:
I feed it either directly from iTunes or from Vimeo via Apple TV. Either of these will display the issue.


If that is the case then it is in fact a different circumstance to other examples (Sony and Blackmagic) where this has occurred before. Previously I've never seen ANYONE be able to make grids appear in these scenarios with a defined user format (DCI / UHD or 1920) on rendered output.

In your example you're saying it happens when you create a "native" 4.6K timeline in Resolve and also in a 4.6K ProRes timeline for FCPx that you then render to 1920 h.264 (even though you're shooting at UHD ProRes) is that right ?

JB
John Brawley
Cinematographer
Atlanta
Georgia
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 9:40 pm

John Brawley wrote:If that is the case then it is in fact a different circumstance to other examples (Sony and Blackmagic) where this has occurred before. Previously I've never seen ANYONE be able to make grids appear in these scenarios with a defined user format (DCI / UHD or 1920) on rendered output.

In your example you're saying it happens when you create a "native" 4.6K timeline in Resolve and also in a 4.6K ProRes timeline for FCPx that you then render to 1920 h.264 (even though you're shooting at UHD ProRes) is that right ?

JB

I'm not very familiar with the previous issues you mentioned so can't comment on them.

As I (possibly unsuccessfully) tried to make clear in my postings with links to files on dropbox, the issue comes up when you're using clips in a timeline of their own native resolution. When the clips are in a timeline that does not match the native resolution of the clips the Resolve image scaling algorithms blur the artifacts via interpolation, so it's not evident. But if you (for example) take a 4.6k raw file, render it in a 4.6k timeline to a prores file, and then bring that file into FCPX, you are hosed... FCPX may or may not show the problem, depending upon the magnitude of the scaling operation (i.e., if you are scaling to or near a multiple of the original resolution, a cross-hatch pattern will appear in the image and will be rendered in the final result).

If you go back into my postings, I supply all of the information and links to files necessary to reproduce the problem deterministically. And I've confirmed these findings with a friend who's running Resolve 12.5 at his studio, along with (of course) the folks at Blackmagic US support.
Offline

John Brawley

  • Posts: 1941
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Chicago Illinois

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 9:59 pm

Gary Yost wrote:I'm not very familiar with the previous issues you mentioned so can't comment on them.


This topic title comes up every few months on this forum for all the BM cameras, and it's also been seen occurring in several Sony cameras.

When you drill down, in every single example I've seen aside from yours, the issue disappears on final output because it's actually a display scaling issue that once you render a file, look at it 1:1, or see it in a recognised final pixel aspect ratio/ size it disappears.

It's like another version of moire. It can also appear or disappear as you change scaling and playback parameters, but isn't really a function of an error in the source footage per se.


Gary Yost wrote:As I (possibly unsuccessfully) tried to make clear in my postings with links to files on dropbox, the issue comes up when you're using clips in a timeline of their own native resolution.


To be perfectly honest I haven't downloaded your files. Mostly when I see this topic come up, the issue disappears once you get the poster to go through the steps we have. I'm not doubting you at all, but I've seen the same "problem" posted a dozen times and until now, it's never made it as far as yours appears to.

Gary Yost wrote:
When the clips are in a timeline that does not match the native resolution of the clips the Resolve image scaling algorithms blur the artifacts via interpolation, so it's not evident. But if you (for example) take a 4.6k raw file, render it in a 4.6k timeline to a prores file, and then bring that file into FCPX, you are hosed... FCPX may or may not show the problem, depending upon the magnitude of the scaling operation (i.e., if you are scaling to or near a multiple of the original resolution, a cross-hatch pattern will appear in the image and will be rendered in the final result).


So let me ask you this.

What happens if you use and render in a "recognised" aspect ratio like 4096 or 3840 (UHD) ?

JB
John Brawley
Cinematographer
Atlanta
Georgia
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 10:43 pm

John Brawley wrote:What happens if you use and render in a "recognised" aspect ratio like 4096 or 3840 (UHD) ?

JB

If I invoke some form of image scaling in Resolve by (for example) putting a 4.6k clip in a 3840 or 4KDCI timeline, the problem totally disappears. And if I put a UHD clip into an HD timeline, the problem disappears.

It's not a moire issue because when you look at individual pixels at 1000% you can clearly see the problem. I've posted quite a few examples of this in the thread and if you're up for it all the data is there for you.

And to reiterate, the support people at Blackmagic US (Veronica has been my lead on this issue) have acknowledged the problem and gave me a .drx file for 4.6k footage on a 4.6k timeline and the workaround does the job adequately for my purposes. They are still working on deciphering what's going on and I'm sure we'll hear more about it soon. I have an extensive background in monolithic complex graphics software development but sensors and debayering are not in my purview. That said, I understand how complicated this stuff can be and have a tremendous amount of empathy for the engineering team. Beyond my observations and the reports of my discussions with the folks in support I'm as stumped as anybody else would be. Bottom line is that I still totally love this camera and am confident that Blackmagic will deal with these sort of issues as they arise. All's good.
Offline

John Brawley

  • Posts: 1941
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Chicago Illinois

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 11:28 pm

Gary Yost wrote:
John Brawley wrote:What happens if you use and render in a "recognised" aspect ratio like 4096 or 3840 (UHD) ?

JB

If I invoke some form of image scaling in Resolve by (for example) putting a 4.6k clip in a 3840 or 4KDCI timeline, the problem totally disappears. And if I put a UHD clip into an HD timeline, the problem disappears.


OK. So it works as expected in commonly used pixel aspect ratios. But in your situation you're wanting to work at sensor native resolutions in the timeline all the way through post till delivery ?

Gary Yost wrote:It's not a moire issue because when you look at individual pixels at 1000% you can clearly see the problem. I've posted quite a few examples of this in the thread and if you're up for it all the data is there for you.


I wasn't at all saying your situation was moire. But display scaling issues that LOOK like this are also manifested in the same way moire problems are. An inherent pattern in the footage that will "ring" at certain combinations. Moire can present or not present in the same footage depending on the playback display, scaling etc. And often just like other examples of this issue.

Gary Yost wrote:
And to reiterate, the support people at Blackmagic US (Veronica has been my lead on this issue) have acknowledged the problem and gave me a .drx file for 4.6k footage on a 4.6k timeline and the workaround does the job adequately for my purposes.



Perhaps but what you're doing is kind of unusual, which is maybe why it hasn't shown up till now.

Can I ask with no disrespect why your timeline needs to be the same as the sensor resolution ? Usual work practice is to work in your target delivery pixel size. Is there a reason you need to post in the sensor native size ?

I ask because it's very normal to oversample on the camera side but edit / post / deliver in common delivery aspect ratios like UHD, 4K DCI or 1920.

Most don't create timelines in the camera sensor aspect ratio like you are (which is also I guess why it doens't exist as a template) I guess this is because historically, you deliver to a certain standard, and the thinking with most CMOS sensors (and the way the ratio of RGB photosites work) is you should ideally oversample, so the 2.5K BMCC makes really nice 1920 footage and the 4.6K makes lovely UHD footage.

If you look at RED it's the same, their cameras generally oversample to deliver beautiful down sampled pixel sizes. When RED was first delivered, an early criticism of their 4K mantra was that you can't measurably get 4K on the screen from a 4K sensor, it needs to be up past 5K on a CMOS / Bayer sensor to even get close to putting 4K of resolution on the screen. Nobody really creates 5120 x 2700 timelines with a RED camera even though that's what it (some of them) shoots. For starters the aspect ratio isn't one that's a traditional aspect ratio.

Now that's not to say what you're doing shouldn't work, but it's just not common workflow practice to do it that way.

Alexa Open gate RAW for example is 3414 x 2198 but no one would really work in that pixel aspect ratio. with an aspect ratio of 1.55 :1

Sony's F65 is an 8K sensor aimed at delivering a nice 4K image.... They drop those files into a timeline that is one of the common delivery resolutions.

Also, many productions use different cameras, working at different resolutions (and codecs) so it makes sense to have a target resolution timeline that everything gets scaled to.

So I guess I'm saying is that the intention with most cameras is to oversample the sensor to get a resolution that's closer to ideals like UHD, and that the normal workflow of post / editing at common delivery pixel sizes means that this is largely the case.

JB
John Brawley
Cinematographer
Atlanta
Georgia
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSat Jul 23, 2016 11:43 pm

John Brawley wrote:
OK. So it works as expected in commonly used pixel aspect ratios. But in your situation you're wanting to work at sensor native resolutions in the timeline all the way through post till delivery ?

...what you're doing is kind of unusual, which is maybe why it hasn't shown up till now.

Can I ask with no disrespect why your timeline needs to be the same as the sensor resolution ? Usual work practice is to work in your target delivery pixel size. Is there a reason you need to post in the sensor native size ?

I ask because it's very normal to oversample on the camera side but edit / post / deliver in common delivery aspect ratios like UHD, 4K DCI or 1920.
JB

It's a little more complicated than that...

1) I'm seeing the same issue with ProRes UHD files in a UHD timeline. I posted examples of this earlier today with files and instructions that you can use to reproduce the same problem (and Blackmagic support has acknowledged the problem with UHD and HD as well... it's not limited to 4.6k).

However.... that's not my workflow so it doesn't really bother me (yet).

2) Regarding your question about my workflow... I've explained it earlier in this thread but it's a long thread so no problem, here 'tis again. I edit in FCPX but grade in Resolve. I shoot Raw for a number of reasons (full 4.6k sensor resolution, ability to adjust white balance/tint, highlight recovery, camera matching, and ostensibly better debayering in Resolve vs the camera). I ingest and make Raw edits and then render BMDFilm ProRes 422HQ (or in some cases 444) at full sensor resolution and drop those 4.6k files into usually an HD timeline (only one of my projects has ever been delivered in 4k). That extra resolution is very valuable to me because I do a lot of punch-ins, pushes and some stabilization. It's one of the reasons why I chose the Ursa Mini 4.6k. I sometimes use the "normal" proxy workflow to round trip to FCPX but the problem with that is if I'm doing anything tricky with compositing (in After Effects), transforms or plugins (which I do a lot) the xml files don't travel accurately back to Resolve. So I pre-bake all of my shots in FCPX using a plug-in called Primaries Exporter, which makes conforming the 1920HD xml once back in Resolve trivial and 100% accurate. (And of course also helps a lot with performance while grading... ProRes HD files instead of UHD or even HD Raw, much faster.)

So the only timeline I'm creating in 4.6k is the one in Resolve that's essentially for transcoding from Raw to ProRes. From then on I'm in HD, both in FCPX and then back in Resolve for grading. I typically use multiple cameras (now the BMPCC, UM4.6k and DJI X5R, which are all different source resolutions) but FCPX handles image scaling quite well as long as the source is clean.

Hope that explains my workflow... I didn't realize that it was so untypical!
Offline

John Brawley

  • Posts: 1941
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Chicago Illinois

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostSun Jul 24, 2016 3:03 am

Gary Yost wrote:


Hope that explains my workflow... I didn't realize that it was so untypical!


Hi Gary,

I don't think it's untypical as a workflow overall, but what is less common, is the 4.6K ProRes transcodes part of that. It sounds a lot like you want the RAW roundtrip advantages up your sleeve but mostly you're staying in ProRes world. I guess it's because you're "hedging" and wanting to keep the most number of options open plus working in both FCPx and AE as well sometimes.... I guess the more "usual" version of what you're doing would be 4096 transcodes of the RAW rather than 4.6K transcodes, but there's no reason why what you're doing SHOULDN'T work, with this issue being addressed hopefully.

I would think as a work around that a 4096 transcode would end up a pretty similar result for a 1920 timeline even with stabilizing and what not, I can't imagine the little extra res makes a whole lot of difference and I guess you could always round trip that specific clip if you really felt you needed it ?

JB
John Brawley
Cinematographer
Atlanta
Georgia
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostMon Jul 25, 2016 3:42 am

I just did did a fairly extensive test today and the workaround functioned well with 4.6k footage on a 4.6k timeline, so I'm good. That said, I'm still seeing issues with UHD clips on a UHD timeline, and although that's not my typical workflow it's something that will be occasionally useful, so I'll continue to discuss all this with BM support.

Onward...

John Brawley wrote:
I don't think it's untypical as a workflow overall, but what is less common, is the 4.6K ProRes transcodes part of that. It sounds a lot like you want the RAW roundtrip advantages up your sleeve but mostly you're staying in ProRes world. I guess it's because you're "hedging" and wanting to keep the most number of options open plus working in both FCPx and AE as well sometimes.... I guess the more "usual" version of what you're doing would be 4096 transcodes of the RAW rather than 4.6K transcodes, but there's no reason why what you're doing SHOULDN'T work, with this issue being addressed hopefully.

I would think as a work around that a 4096 transcode would end up a pretty similar result for a 1920 timeline even with stabilizing and what not, I can't imagine the little extra res makes a whole lot of difference and I guess you could always round trip that specific clip if you really felt you needed it ?

JB
Offline

Soeren Mueller

  • Posts: 595
  • Joined: Tue Sep 04, 2012 2:21 pm
  • Location: Düsseldorf, Germany

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostMon Jul 25, 2016 10:40 am

That looks a lot like the strange debayer "artefact" I (and others) encountered several times on the Pocket Cam - especially in lens flares or harsh lighting conditions. It showed up with in-camera debayer and Resolve debayer (which of course makes sense if they both use the exact same algorithm). Guess I'll ask support for that drx as well.

And by the way - thanks Gary for 3ds Max :)
Offline
User avatar

Tom

  • Posts: 1626
  • Joined: Wed Aug 22, 2012 5:08 am
  • Location: Manchester, UK

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostMon Jul 25, 2016 11:15 am

Soeren Mueller wrote:
And by the way - thanks Gary for 3ds Max :)



Gary, are you THE Gary Yost, involved in 3ds??

If so - as someone who has used 3DS for 15 years and taught it for 4 - thanks also!
Tom Majerski
http://tetragrade.com/
http://www.imdb.com/name/nm5157752/
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostMon Jul 25, 2016 1:04 pm

Soeren Mueller wrote:That looks a lot like the strange debayer "artefact" I (and others) encountered several times on the Pocket Cam - especially in lens flares or harsh lighting conditions. It showed up with in-camera debayer and Resolve debayer (which of course makes sense if they both use the exact same algorithm). Guess I'll ask support for that drx as well.

Interesting. And re the .drx workarounds.... note that I've posted tests of these earlier in this thread (4.6k on 4.6k timeline, UHD on UHD timeline, and HD on HD timeline). HD on HD timeline doesn't seem to show the artifact unless you're in windowed mode. The only one of the .drx's that currently work for me is the 4.6k version. I'm still seeing the artifact with UHD-on-UHD and windowedHD-on-HD. But the 4.6k is the one that I typically use, so I'm happy.
Soeren Mueller wrote:And by the way - thanks Gary for 3ds Max :)

You're welcome, Soeren. :)
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostMon Jul 25, 2016 1:07 pm

Tom wrote:Gary, are you THE Gary Yost, involved in 3ds??

If so - as someone who has used 3DS for 15 years and taught it for 4 - thanks also!

That was me, Tom... a long long time ago! (I'm happy that you got some use out of our code.)
Offline

Soeren Mueller

  • Posts: 595
  • Joined: Tue Sep 04, 2012 2:21 pm
  • Location: Düsseldorf, Germany

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostMon Jul 25, 2016 10:18 pm

Gary Yost wrote:Interesting. And re the .drx workarounds.... note that I've posted tests of these earlier in this thread (4.6k on 4.6k timeline, UHD on UHD timeline, and HD on HD timeline). HD on HD timeline doesn't seem to show the artifact unless you're in windowed mode. The only one of the .drx's that currently work for me is the 4.6k version. I'm still seeing the artifact with UHD-on-UHD and windowedHD-on-HD. But the 4.6k is the one that I typically use, so I'm happy.


Yeah I've looked at the frames you have posted. Well HD-on-HD (non windowed) is downscaled in camera, right? That would explain why the "artefacts" aren't showing up in that case.
I have seen the exact same type of almost "labyrinth"/"maze" like artefact pattern in the past in HD-on-HD (1080p is the native sensor resolution) RAW and Prores from the BM Pocket Camera. I'll have to scan through my archives again tomorrow maybe I can find a DNG.

Sometimes the client didn't notice it or I had to "resolve" it by slightly blurring the frame. But I would be interested if there is some sort of solution from BM that doesn't require "brute force" blurring of the whole frame. (which is basically what a 0.5 pixel offset does as well as you have rightly noted)

Gary Yost wrote:
Soeren Mueller wrote:And by the way - thanks Gary for 3ds Max :)

You're welcome, Soeren. :)


Like Tom I have used 3ds Max for a long time.. I think it was my first ever CG program I used in the early 1990ies... even before I ever got into contact with Photoshop ;)
Offline
User avatar

Tom

  • Posts: 1626
  • Joined: Wed Aug 22, 2012 5:08 am
  • Location: Manchester, UK

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostTue Jul 26, 2016 8:36 am

Gary Yost wrote:
Tom wrote:Gary, are you THE Gary Yost, involved in 3ds??

If so - as someone who has used 3DS for 15 years and taught it for 4 - thanks also!

That was me, Tom... a long long time ago! (I'm happy that you got some use out of our code.)



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.
Tom Majerski
http://tetragrade.com/
http://www.imdb.com/name/nm5157752/
Offline
User avatar

Gary Yost

  • Posts: 87
  • Joined: Fri Jan 17, 2014 2:03 pm

Re: "screen-door" crosshatching on Ursa Mini 4.6k images

PostTue Jul 26, 2016 4:41 pm

Soeren Mueller wrote: But I would be interested if there is some sort of solution from BM that doesn't require "brute force" blurring of the whole frame. (which is basically what a 0.5 pixel offset does as well as you have rightly noted)

The workaround .drx file that I got doesn't appear to use the 0.5 pixel offset to fix it. When I apply the .drx the offset stays at 0.0 but the cross-hatched pattern is gone.

I tested their workaround for windowed HD in an HD timeline and that seems to work (and full-sensor HD in an HD timeline didn't seem to need the fix). UHD full-sensor in a UHD timeline is still problematic (but not part of my current workflow) and they say that the fix will work for UHD windowed in a UHD timeline (but I haven't tested that yet).

It sounds like you go back even farther than Max... all the way to 3D Studio/DOS. That is _really_ ancient history. We are getting old..... ;)
Next

Return to Cinematography

Who is online

Users browsing this forum: Bing [Bot], Denny Smith, Douglas Bischoff and 10 guests