Blackmagic Forum

Phillip Bergman wrote:

Deyan Parouchev wrote:Ok, is there someone here which send to BM his camera and get the camera back clean of this issue ?
Is there any clean camera out ? Is it possible to correct with a future firmware ?

I believe Eli Hershko and Jamie LeJeune have both had their cameras successfully fixed of this problem by BMD.

As far as I can tell, the RMA has eliminated the problem on my camera. Here is a link to a DNG from my Ursa Mini 4.6K post RMA running firmware 4.0:

https://drive.google.com/open?id=0B1bnfGXKHqpcTVNDb3AwejNsSkE

Please take a look and let me know if anyone is able to find the odd/even pattern in it, or if they can see any difference when applying the "bayer green split" in Corner Fix.

Gary Yost sent his in for RMA as well and (as reported earlier in this thread) his testing revealed that the RMA had fixed the problem on his camera as well.

Not completely gone unfortunately.

roger.magnusson wrote:Not completely gone unfortunately.

Post_RMA_UM46_firm4-0.png

How about this footage> https://spaces.hightail.com/receive/xaVYK

Roger, that image from Jamie looks quite good expanded on my iPad Retina Air . And I think it's very important to judge as a moving picture in which I suspect Jamie can't see any problem. If it's true these 4.6K sensors are suffering from different green levels on alternating lines of the bayer, it's well corrected for Jamie, but, would be better of course if the 4.6K sensor wasn't the source of the problem. As these cameras are returned and come back with something corrected (big secret what actually is done), they have to be judged as Cinema cameras, not judged with the criteria one would apply to a museum quality 16x20" art print still life. Not trying to be difficult here, but just reminding people every 500 posts of that reality. When you have a camera that doesn't cut it producing a moving picture, may hellfire rain down.


Sent from my iPad using Tapatalk

Jamie LeJeune wrote:Please take a look and let me know if anyone is able to find the odd/even pattern in it, or if they can see any difference when applying the "bayer green split" in Corner Fix.

The problem seems to be present, although it's less pronounced in the brighter areas and more pronounced in the shadowed area of the top right corner. CornerFix was able to correct this.

rick.lang wrote:Roger, that image from Jamie looks quite good expanded on my iPad Retina Air . And I think it's very important to judge as a moving picture in which I suspect Jamie can't see any problem. If it's true these 4.6K sensors are suffering from different green levels on alternating lines of the bayer, it's well corrected for Jamie, but, would be better of course if the 4.6K sensor wasn't the source of the problem. As these cameras are returned and come back with something corrected (big secret what actually is done), they have to be judged as Cinema cameras, not judged with the criteria one would apply to a museum quality 16x20" art print still life. Not trying to be difficult here, but just reminding people every 500 posts of that reality. When you have a camera that doesn't cut it producing a moving picture, may hellfire rain down.

It is true that it's not a stills camera nor should we expect it to be. However, using a raw CDNG image to test whether the camera is applying a proper debayer is a valid method. The debayering fault only causes visible problems during certain post workflows, so rather than having to test every workflow to ensure that the issue has been eliminated, it is much more efficient to simply dig deep into a single image to see if the cause of the problem (the odd/even pattern) still remains or not.

EDIT: And I do see the clear differences highlighted in Earl's post above.

Yea looking at that DNG in resolve, that pattern is still definitely there. Well now I'm depressed. Had high hopes that this issue would be resolved. Sent my camera in for RMA a couple days ago...fingers crossed, but it seems as though they don't really have a fix, just a way to make it less obvious.

Still there ! I can see the exact same improvements with my unit, and it's also more noticeable in darker areas of the image.

I'm leaning more and more towards the FS7


Sent from my iPhone using Tapatalk Pro

Earl R. Thurston wrote: seems to be present, although it's less pronounced in the brighter areas and more pronounced in the shadowed area of the top right corner. CornerFix was able to correct this.

Earl, can you describe to me how you processed my DNG explaining what software you used and what settings. If I am able to replicate the same results on my Mac Pro, I would like to send the results to BMD support. Thanks!

rick.lang wrote:Roger, that image from Jamie looks quite good expanded on my iPad Retina Air . And I think it's very important to judge as a moving picture in which I suspect Jamie can't see any problem. If it's true these 4.6K sensors are suffering from different green levels on alternating lines of the bayer, it's well corrected for Jamie, but, would be better of course if the 4.6K sensor wasn't the source of the problem. As these cameras are returned and come back with something corrected (big secret what actually is done), they have to be judged as Cinema cameras, not judged with the criteria one would apply to a museum quality 16x20" art print still life. Not trying to be difficult here, but just reminding people every 500 posts of that reality. When you have a camera that doesn't cut it producing a moving picture, may hellfire rain down.


Sent from my iPad using Tapatalk

Rick, to "provoke the issue" so to speak, you need to be on a zoom level where the intrinsic maze pattern in the image starts to interfere with the display and you need to use a scaling algorithm that reveals the issue. With those two prerequisites taken into account, I don't think the footage produced by Jamies fixed camera is terrible at all since final render will probably be quite good.

What bothers me is the loss of detail or the "false" detail that results from this issue. I don't really subscribe to the theory that it's a debayering issue, I think it's a miscalibration that can be hidden by debayering in a slightly different way where nearby green photosites aren't allowed to differ too much.

Anyway, I'm no expert. Will report when my camera returns from BMD.

Jamie LeJeune wrote:Earl, can you describe to me how you processed my DNG explaining what software you used and what settings.

The original DNG's are simply opened in Photoshop via Adobe Camera Raw (ACR) without any adjustments.

The "fixed DNG" are created by first running the original DNG through CornerFix and applying a BayerGreenSplit500.cpf profile (downloaded from https://sites.google.com/site/cornerfix/using-cornerfix/maze-patterns-1) and saving that as a new DNG. I then open that DNG in Photoshop via ACR as well.

To demonstrate the potential for scaling moiré, I resize both images by a percentage that I know will reveal the problem, such as 55%, using bilinear interpolation. Only the original shows scaling moiré; the fixed one doesn't.

The other work is simply cropping and highlighting portions of each DNG for the purposes of posting here. My 400% blow-ups of the odd/even pixels are scaled using nearest-neighbour interpolation to enlarge the actual pixels without blending them together.

Earl R. Thurston wrote:

Jamie LeJeune wrote:Earl, can you describe to me how you processed my DNG explaining what software you used and what settings.

The original DNG's are simply opened in Photoshop via Adobe Camera Raw (ACR) without any adjustments.

The "fixed DNG" are created by first running the original DNG through CornerFix and applying a BayerGreenSplit500.cpf profile (downloaded from https://sites.google.com/site/cornerfix/using-cornerfix/maze-patterns-1) and saving that as a new DNG. I then open that DNG in Photoshop via ACR as well.

To demonstrate the potential for scaling moiré, I resize both images by a percentage that I know will reveal the problem, such as 55%, using bilinear interpolation. Only the original shows scaling moiré; the fixed one doesn't.

The other work is simply cropping and highlighting portions of each DNG for the purposes of posting here. My 400% blow-ups of the odd/even pixels are scaled using nearest-neighbour interpolation to enlarge the actual pixels without blending them together.

Thank you very much for the detailed description Earl. As I personally don't ever use ACR in my workflow, I'll have to do some testing to see whether the Cornerfix reveals any difference with DNG images viewed inside of Resolve.

Jamie LeJeune wrote:I'll have to do some testing to see whether the Cornerfix reveals any difference with DNG images viewed inside of Resolve.

I recall reading from some other people that Resolve doesn't pay any attention to the "BayerGreenSplit" setting, but it's worth giving it a try to confirm.

My updated summary post from page 6 one more time:


1. Wrong debayering of second green pixel produces semy-invisible fixed pixel grid which is partially hidden under the sensor noise. As a result at some zoom or scale levels in various players and apps this invisible grid may produce highly visible cross-hatch moire-like pattern.
2. Depending of image contrast, added sharpen and noise reduction amount, and player scaling method this pattern may be visible or not visible at all.
3. In BMMCC which is limited to 1920x1080 resolution this makes sensor Noise and FPN more visible (it behaves like some kind of shadow noise and FPN sharpening, adds additional digital artifacts to noise texture) and this limits the amount of visually usable shadow details.
4. People noticed this effect in BMPCC and BMPC cameras. In BMPCC it is harder to see because it is slightly noisier than BMMCC and pixel pattern more hidden under the noise.
5. This effect depends of camera firmware version.
6. This problem can be fixed with fix in CornerFix app https://sites.google.com/site/cornerfix/using-cornerfix/maze-patterns-1 with applying a BayerGreenSplit500.cpf settings. This fix works only in ACR. All other RAW processing apps ignores it.
7. BM support team answer: "this is currently under investigation by our Development team"
8. BM team RMA few cameras but results are random and not perfect.
9. As a temporary solution for this problem shifting image position by setting X Y position to 0.5 works very well (note that in Resolve this works only with RAW footage, but in Adobe apps it works with both ProRes and RAW footage)
UPDATE: In Resolve, simply use the "pan/tilt" setting in the Color Tab (same values of 0.5 each), instead of "xy position" in the inspector. Should work for ProRes-Footage as well ...

We are working on this.

We have a software build we are working on that will allow users to run black calibration in the field. This should show the same sort of results as those customers who have had their cameras improved recently under RMA.

It takes less than 30 seconds and is simple to carry out in the field by any user.
I'm not going to go into more detail on this but a build is on the way and we will get it to you as soon as we can.

Thank you!


Sent from my iPhone using Tapatalk Pro

Tim Schumann wrote:We are working on this.

We have a software build we are working on that will allow users to run black calibration in the field. This should show the same sort of results as those customers who have had their cameras improved recently under RMA.

It takes less than 30 seconds and is simple to carry out in the field by any user.
I'm not going to go into more detail on this but a build is on the way and we will get it to you as soon as we can.

Thank you Tim. I appreciate the (belated) official acknowledgement of the widespread debayering fault. I also really truly would appreciate more detail and certainly hope a detailed explanation is forthcoming.
Specifically, it would be helpful to know:
Does Dmitry's explanation match what BMD's engineering team found to be the cause of the problem?
Considering that even the RMA fix hasn't been 100% successful, what options remain for users still plagued with lingering artifacts?

Tim Schumann wrote:We are working on this.

We have a software build we are working on that will allow users to run black calibration in the field. This should show the same sort of results as those customers who have had their cameras improved recently under RMA.

It takes less than 30 seconds and is simple to carry out in the field by any user.
I'm not going to go into more detail on this but a build is on the way and we will get it to you as soon as we can.

Great news! Hope this update will be not only for UM4.6k but for other cameras too.

@Tim Schumann:
Wow, that is some good news!
Thanks for the feedback!

@Dimity Shijan:

Dmitry Shijan wrote:9. As a temporary solution for this problem shifting image position by setting X Y position to 0.5 works very well (note that in Resolve this works only with RAW footage, but in Adobe apps it works with both ProRes and RAW footage)

[/quote]
In Resolve, simply use the "pan/tilt" setting in the Color Tab (same values of 0.5 each), instead of "xy position" in the inspector. Should work for ProRes-Footage as well ...

But hopefully, soon this will not be necessary any more ...

BAM!

They spoke!

Blackmagic, YES, this is what we are asking for. You can tell us "we know its an issue, and a software fix that we wont discuss further is coming soon" and that makes it MUCH easier to buy the camera.

Please communicate like this with us in the future! it makes SUCH a difference. Thank you!

+1 to Kyles thoughts


Sent from my iPhone using Tapatalk Pro

Tim Schumann wrote:We have a software build we are working on that will allow users to run black calibration in the field.

This is absolutely great news, not just for this specific issue but for others as well, such as fixed pattern noise. Hopefully this will available for both models (4K and 4.6K)

And thank you for the response. Even if you can't provide more details, acknowledgement is at least what most of us have been asking for.

Tim Schumann wrote:We are working on this.

We have a software build we are working on that will allow users to run black calibration in the field. This should show the same sort of results as those customers who have had their cameras improved recently under RMA.

It takes less than 30 seconds and is simple to carry out in the field by any user.
I'm not going to go into more detail on this but a build is on the way and we will get it to you as soon as we can.

THIS THIS THIS

Thank you BlackMagic. This makes me happy/hopeful again.

Mine has been collected today to have the issue fixed, I will keep people posted on how things go.

Interesting regards calibration built into software, does this mean you calibrate once and then it's done or calibrate based on your different shooting environments? Makes you wonder if it's that simple why it hasn't already been done from the factory and why they seem to be having cameras for quite a while whilst being fixed, unless it's the latest firmware that has changed something that means the cams now need another calibration step, would be great for some clarification on this.

Thanks very much for the statement tho Tim it really does help put our worries to rest a little.

I would think you could calibrate in the field anytime, such as the start of every day on location. If not every day, then every day that there are changing conditions, for example, a very hot day, a very cool day, a very wet day, a very dry day. If it was a part of your normal camera check startup, you wouldn't even notice the time or effort.


Sent from my iPad using Tapatalk

Yes you will be able to calibrate in the field any time but it won't be required that often.

Tim Schumann wrote:Yes you will be able to calibrate in the field any time but it won't be required that often.

That's awesome. Thanks for the updates, Tim.

Tim,
Thanks for the update but seriously wish u would have communicated this before I sent in an RMA and spent the money to do so. All the more reason for transparency.

EDIT: I do appreciate the info now though. Please keep it going in the future. Thanks!


Sent from my iPhone using Tapatalk

Coming from RED and reduser.net, only good can come from customer/employee/owner communication. Sure it takes time but that's how devout followers are made. That's one of the main reasons RED has a cult following. Thanks again Tim for the info!


Sent from my iPhone using Tapatalk Pro

Hi Tim,
Will this upcoming software build be only for the Ursa/Ursa Mini or for other cameras, such as the BMMCC, as well?

Luca Di Gioacchino wrote:Hi Tim,
Will this upcoming software build be only for the Ursa/Ursa Mini or for other cameras, such as the BMMCC, as well?

This.

Please don't leave us BMMCC users out.

Larry Sullivan wrote:

Luca Di Gioacchino wrote:Hi Tim,
Will this upcoming software build be only for the Ursa/Ursa Mini or for other cameras, such as the BMMCC, as well?

This.

Please don't leave us BMMCC users out.

Apparently, the build will only be for the Ursa/Ursa Mini, and who knows when that will be ready. If you are the owner of a BMMCC and have to RMA it, don't hold your breath and send it in.

BMMCC is a current camera, not outdated. It never was updated yet. Black Shading is essential option for many professional cameras so why don't implement it to BMMCC with some other useful options like LUT support, more customized overlay options and assignable buttons too?

Don't dream too much for LUT support :p It requires more processing power.

(but you can check the Video Assist for that, just saw that an update has been released with LUT support)

Valentin Remy wrote:Don't dream too much for LUT support :p It requires more processing power.

(but you can check the Video Assist for that, just saw that an update has been released with LUT support)

LUTs can be different. There is always an option to limit the size/resolution of accepted in-camera LUT. If the camera can output in LOG and REC i think there is some kind of build-in LUT-like color transformation present.

Dmitry Shijan wrote:BMMCC is a current camera, not outdated. It never was updated yet. Black Shading is essential option for many professional cameras so why don't implement it to BMMCC with some other useful options like LUT support, more customized overlay options and assignable buttons too?

Essential like it is on the Alexa ?

JB

John Brawley wrote:

Dmitry Shijan wrote:BMMCC is a current camera, not outdated. It never was updated yet. Black Shading is essential option for many professional cameras so why don't implement it to BMMCC with some other useful options like LUT support, more customized overlay options and assignable buttons too?

Essential like it is on the Alexa ?

JB

RED, Phantom, Sony F5 and F55, SI-2k, Panasonic P2 cameras have Black Shading option.
From other forums i read:

Alexa just have a silent cooling system that adjust temperature to keep it consistent. To get a new black shade you have to send an Alexa back to arri, or qualified service house.

and

Alexa does not have a blackshading function to my knowledge, however it is known that the Alexa exhibits hot pixels and other noise artifacts at extremely slow shutter speeds, such as 1 second exposures as you might use for quick impromptu timelapse work. If it did have a blackshade function, there's a good chance it might eliminate that problem, as similar artifacts are present on RED cameras if you try to shoot low FPS without re-doing your black shade. Here's an example of the artifacting on Alexa and a discussion on it: https://litpixl.com/2011/10/26/image-ar ... er-speeds/

Maybe the point I'm making is that it's not essential ?

Maybe the fact that Alexa can do it's blackshading by another method means Blackmagic cameras can as well ?

Seeing as they share sensor design and setup like cooling and dual read outs ?



JB

John Brawley wrote:Maybe the point I'm making is that it's not essential ?

Maybe the fact that Alexa can do it's blackshading by another method means Blackmagic cameras can as well ?

Seeing as they share sensor design and setup like cooling and dual read outs ?



JB

I would say given the noise pattern issue it's needed


Sent from my iPhone using Tapatalk Pro

John Brawley wrote:Maybe the point I'm making is that it's not essential ?

Well, I don't know whether you've run into the debayer/crosshatch issue on your Ursa Mini 4.6K cameras, but for those of us that have had the problem (and it seems that many people have) a solution is necessary.
It's not important how BMD solves the problem. All that matters is that they do actually solve it.

The point is...

Blackmagic cameras do have a black balance function.

It's just not currently available for a user to manually override like it is on some other cameras. And that's not so unusual as is being inferred.

Jb

John Brawley wrote:The point is...

Blackmagic cameras do have a black balance function.

It's just not currently available for a user to manually override like it is on some other cameras. And that's not so unusual as is being inferred.

Jb

Please forgive my ignorance here, but does automatic v. manually triggered black balance affect the debayer/crosshatch problem? Or, did I accidentally step into your reply to an earlier comment that was about an entirely different question?

Received my calibrated camera from BMD today. It's better, a lot better. You can still see cross hatching if you go looking for it, even in footage that isn't underexposed according to false color. If I use the smoother scaling algorithms in Resolve it now goes away completely, but unfortunately not in Fusion (at least not in the preview window). Playing ProRes directly from the CFast card on a retina MacBook Pro still also shows the issue in the QuickTime player. Not good for handing over unprocessed footage to clients.

Will wait for the black calibration in the upcoming firmware and then decide what to do I guess.

I hope the black calibration build will be made available for the BMMCC as well. Last I heard, it will only be for the Ursa Mini.

Jamie LeJeune wrote:
Please forgive my ignorance here, but does automatic v. manually triggered black balance affect the debayer/crosshatch problem? Or, did I accidentally step into your reply to an earlier comment that was about an entirely different question?

It's not something that I am able to speak to, however, I was trying to illustrate that just because there's currently no user selectable black balance, doesn't mean the camera doesn't HAVE a black balance. The Arri Alexa family being a great example of another camera that does not have a user selectable black balance.

What's more, go look at forums for cameras that DO have manual black balance features and you'll see more threads about when where why and now not to do it, not to mention when it doesn't work. It's not the magic bullet some think it is, and frankly you spend so much time doing it when it's manual and I'm not sure you get a better result.

I had issues on an F55 recently, and we basically had to what they call APR at least once a day to ensure we didn't have dead pixels. Every day ! RED also have their caveats where they seem to suggest doing a black balance depending on how hot your environment is, or how long your takes are (cause their cameras heat up as you record for longer times) not to mention the fan noise.

There are many approaches to thermal management / black balance / FPN and hot pixels. I think Blackmagic, following Arri's approach, have got a lot correct, notwithstanding the title of this thread.

JB

John Brawley wrote:
It's not something that I am able to speak to, however, I was trying to illustrate that just because there's currently no user selectable black balance, doesn't mean the camera doesn't HAVE a black balance. The Arri Alexa family being a great example of another camera that does not have a user selectable black balance.

What's more, go look at forums for cameras that DO have manual black balance features and you'll see more threads about when where why and now not to do it, not to mention when it doesn't work. It's not the magic bullet some think it is, and frankly you spend so much time doing it when it's manual and I'm not sure you get a better result.

I had issues on an F55 recently, and we basically had to what they call APR at least once a day to ensure we didn't have dead pixels. Every day ! RED also have their caveats where they seem to suggest doing a black balance depending on how hot your environment is, or how long your takes are (cause their cameras heat up as you record for longer times) not to mention the fan noise.

There are many approaches to thermal management / black balance / FPN and hot pixels. I think Blackmagic, following Arri's approach, have got a lot correct, notwithstanding the title of this thread.

JB

Thank you for the detailed explanation. I'm sure it is a very delicate balance to get right. It seems BMD could be making a switch to manual based on what Tim Schumann wrote above. I agree that auto is better, one less thing to worry about, but I'll be happy doing it manually if it does eliminate the problem.

I saw in another thread on timecode you wrote that you are using three Ursa Mini bodies. Have you run into the crosshatching issue with any of them?

Okay so after a technician looked at my camera I have just received word that BM are sending me a completely new camera, fingers crossed I get one with this issue solved.

Will keep you posted.

Jamie LeJeune wrote:
I saw in another thread on timecode you wrote that you are using three Ursa Mini bodies. Have you run into the crosshatching issue with any of them?

I've just finished a 7 week shoot with three bodies (actually four very occasionally) and no, we've not been bitten by crosshatching, magenta corners or FPN.

The cameras have performed magnificently, better than I hoped. This is the first time I've shot a series using them as the A camera.

I shot ProRes 444 and never once changed from ISO 800.

We shot for 7 weeks straight and I'm about to go and shoot for 10 days in the very far remote north of Australia. It's a four day drive to get there from where I am now and the average daily tempreture is 45 Deg Celsius.

Right now I'm sitting in the grade of the third episode. Everyone here at the post house keeps commenting about how great the pictures look. All the back end guys that do the transcoding, tech checks and archiving have said how impressed they are by the pictures.

I have been helping out a fellow DP who's doing a Netflix original show next year. They just tested RAW on RED EPIC DRAGON, RED WEAPON, SONY F55, VARICAM and URSA MINI 4.6K as well as ALEXA MINI as a reference.

Right now he's down to RED WEAPON or Ursa Mini. The RED will probably get the nod, only because it does higher frame rates at 4K. The DP prefers the look of the Ursa (and he said closest to the Alexa that he prefers) but he's also being practical re frame rates as that's what his show needs. Netflix stupidly don't consider the Alexa Mini good enough in res.

Umm, so no, my long winded answer is, no we've not seen it present as a problem here on the show I'm on.

JB

Great to hear JB! I have pretty much fell into the group that is shooting it's mini 4.6k exclusively. I am testing it with an epic weapon tomorrow to see if there is ever a time I would want 8k... but from all I've seen out of that camera so far it's still the 4.6k for me as far as DR and colors go... especially colors.

It is fairly stupid that Netflix excludes thebursa min and Amira when they do really good in camera up-scaling. In my experience it holds more detail than red 6k. Hopefully this will allow the UM4.6k an opportunity to get some traction on higher level productions though

As always thanks for your input JB