Blackmagic Forum

Hey, After Shijan of BMCUSER mentioned he could see some strange pixels after updating to 4.7 for the BMMCC that he could not see on the previous version I decided to check my own.

I can confirm that I am seeing the same odd pixels. They move with the sensor not the image. Also 4.7 has not fixed the cross hatching and need to pixel shift pan and tilt by 0.5 in resolve.

I am not sure if mine were present before 4.7

Shot in RAW 25p. Gave it a good blow out before testing, these aren't caused by something on the ir glass.

Here are my samples. Fixed dots all around the sensor after 4.7 BMMCC update. I checked old footage and there are no any dots before.

And i can confirm now that this is not a sensor dust. It is odd bug in firmware 4.7.
Here is link to RAW samples shoot with different firmware and different shutter angles: https://www.dropbox.com/s/ivmas61n2dk9s ... t.zip?dl=0

Thanks for the update Shijan. It's good to know it wasn't there in the previous firmware.

Everyone with a BMMCC on v4.7 I urge you to check your sensor and report back with your results. Let's see if this is an issue for every single unit.

Is there a possibility that someone from BMD could check their in house units and see if this is also occurring for them on the 4.7 firmware?

Also if another firmware update is pushed through to correct the issue, some valuable additions would be to correct the crosshatching in davinci resolve. You can see the effect happening in my sample pictures when shooting RAW. It's tedious to have to shift the pan and tilt by 0.5 for every clip.

Another addition would be to have the recording codec shown over the hdmi display. Unlike the pocket camera this is not a feature. It'd really help to reassure the user of their codec. Especially since you can now change codec via sbus, with no visual feedback as to what the camera is recording in this could get dangerous with accidental button presses.

Toggle peaking and zebras via sbus would also be extremely valuable.

Thank you for the continued updates.

Ryan, the recording frame rate and resolution setting is on the top left corner of the monitor on both the Video Assist and SmallHD monitors, which show the receiving resolution frame rate of the signal, so it is. It necessary to have the camera place this in the bottom camera settings line. The Pocket Camera shows this on its monitor, as it has a built in monitor, the Micro camera lacking a monitor, uses the attached monitor status line to get this frame rate / resolution setting info displayed.

Camera firmware is not going to correct a Resolve display issue, I think you need to do that in Resolve’s firmware.

Toggling Focus peaking and Zebras would be nice, especially the Zebra. Since the Micro uses an external monitor, I use the monitor’s peaking settings and turn this off in the camera, so I can get a clean screen very quickly. However, I do use camera Zebras to accurately get overexposure/clipping info, so toggling this with SBus would be handy.
Cheers

Thank you for the response Denny. I know that the frame rate is already displayed and have no issue with that nor did I mention it as an issue. Further on the small hd dp4 the frame rate is actually in the bottom left corner and I don't believe the resolution is displayed as the BMMCC only records in HD.

You are misinformed for the codec as firmware 4.7 added the ability to change codec via sbus. For my unit using the smallhd dp4 the codec is not displayed on screen. I think this is a basic feature that is avaliable on every other BM camera. The micro should have it and make it a toggle, if you don't want clutter simply turn it off. I do find this an issue or inconvenience. This is further a problem now that you can create a remote that changes the codec and potentially change it accidentally.

But the main issue at hand is of course the stuck pixels.

Thank you.

Ryan, you are completely correct, my apologies, I missed the bit where codec can be changed via SBus, which would require a display to know what it is. I haven’t applied it to my camera yet, as I am waiting to get some before footage before doing so, after some reports of pixel issues. Thanks for the correction. My SmallHD 501displays frame rate and resolution (yes the Micro Cinema is 1080 only, but the display shows 29.97 1080p in the upper right hand corner, as does the Video Assist. Other monitors like the DP4 may display it elsewhere of course.
Cheers

Hi,

We're looking into report of the stuck pixels after the v4.7 update and have a fair idea of what's going on. We'll update in the next few days to the progress of the fix.

Awesome thank you very much Kristian!

Yes, thanks for taking fast action. I think I will hold off on updating my camera until,you report back.
Cheers

Kristian Lam wrote:Hi,

We're looking into report of the stuck pixels after the v4.7 update and have a fair idea of what's going on. We'll update in the next few days to the progress of the fix.

Thanks Kristian!

Please could you guys enable a black shading calibration on the Micro from the menu like you did on the Ursa Mini?

Thanks!

Tommaso Alvisi wrote:Thanks Kristian!

Please could you guys enable a black shading calibration on the Micro from the menu like you did on the Ursa Mini?

Why do you need black shading calibration?

Probably it may help to remove Fixed Pattern Noise and this allow to recover more information from shadows and extend dynamic range. Currently Fixed Pattern Noise can be removed only in pots by substracting Fixed Pattern Mask layer as described in this thread viewtopic.php?f=2&t=19422 Due different cooling systems Fixed Pattern Noise in Micro Cinema Camera is more visible than in Pocket Cinema Camera.

You can see some workarounds about extending dynamic range here viewtopic.php?f=21&t=65149

Black shading does not target FPN in the URSA Mini 4.6K (Pro). It's purpose is to minimize black balance/offset drift for the 4.6K sensor.

CaptainHook wrote:Black shading does not target FPN in the URSA Mini 4.6K (Pro). It's purpose is to minimize black balance/offset drift for the 4.6K sensor.

Ah interesting, how would FPN be targeted?

My assumption is that the difficulty lay in not also reducing the cameras dynamic range but I'd have no idea how it'd be done.

A question a lot of us have is why the pocket seems to have none and the micro seems to be so affected? I've heard some people say it's the cooling system, some say that it's the left over circuitry from trying to make it global shutter. Really interesting stuff.

Is it something that can realistically be fixed in firmware while keeping acceptable IQ?

Thanks for the replies!

CaptainHook wrote:Black shading does not target FPN in the URSA Mini 4.6K (Pro). It's purpose is to minimize black balance/offset drift for the 4.6K sensor.

I think black shading = 'magically fix sensor issues" for many people - probably cos they don't really have any significant comprehension about what it actually does (me included)

I'm guessing here but I'm thinking the stuck pixels thing is maybe because some sort of fix for bad pixels on the sensor which has been active in previous firmware maybe went missing this time? (ie its not making bad pixels it's more a case of not hiding them like it used to)

Kristian Lam wrote:

Tommaso Alvisi wrote:Why do you need black shading calibration?

to mask stuck or "dancing" pixels...

I wonder if it would be possible to let the camera's "fix" stuck pixels on it's own. Like JVC, Sony and others do!!

Offcoarse you can fix the Stuck pixels now with Resolve.
But for live video you are still in trouble if you have a stuck or hot pixel in your camera.

This is a major issue why i don't spend money on a few ursa pro's for live video as i'm afraid i will run into trouble within a few months with several stuck pixels in a set of 6 cameras. (Yes 6 cameras. We run a 4K OBV and want to have 6 cameras with that OBV! )

Camera v4.7.1 is now and available from our website.

Thanks Kristian, will down load it now.
Cheers

Thanks for the speedy fix, I'll test it out tomorrow and post an update on my end.

Kristian Lam wrote:Camera v4.7.1 is now and available from our website.

Thanks Kristian!

Seems pretty solid. I intentionally went handheld to see if anything was moving with the micro shake. all the splotchy looking stuck pixels seem to be gone from what I can tell.

The only thing of note was that I did find one or two pink pixels but it only for a second or so. it seems to be caused by the drastic change in colours going from brown/gold to black. So I assume there is a stuck pixel there and the fix for it is working to cover it up but me constantly moving it in and out of the black letter is giving it a hard time.



Otherwise it would seem it's fixed, nothing I or anyone would notice shown at normal viewing but I would be interested to test out a macro lens and see what happens, too bad I don't have one

Other things are.
-Please put the codec on the display in the top left corner with the ability to toggle it off for those using the video assist.
-cross hatching is still present.

Look forward to see other people do better tests than mine to see if it's fixed or not.

Thank you!

Ryan Payne wrote:-cross hatching is still present.

Just use this Power Grade node to fix it https://ursa-mini-fpn-grid-pattern-nois ... 18/fix-46k

Dmitry Shijan wrote:

Ryan Payne wrote:-cross hatching is still present.

Just use this Power Grade node to fix it https://ursa-mini-fpn-grid-pattern-nois ... 18/fix-46k

Still this shouldn't be a necessary step.

Hey everybody!

I’m new to this forum. I own a Blackmagic Micro Cinema Camera and apart from a problem that recently occured, I’m happy with it.

After updating my BMMCC to 4.7.1, I mentioned clusters of pixels flashing for one frame in a low light situation (see pictures below).

I tested the camera in normal light conditions and with different ISO and shutter settings (ISO 800 / shutter 180°, ISO 800 / 360°, ISO 1600 / 180°, ISO 1600 / 360°). The flashing of pixelclusters remained. All the footage was captured in RAW and the camera was well warmed up. The flashing occurs at random positions, at random times and at random size but always for one frame.

I can’t assure that this problem didn’t occur with older firmwares. Though I checked some older footage and didn’t find any of this flashings.

Below you can see a situation when the flashing occurred. I added a picture before flashing, one when the flash occurred and one of the magnified flash. The stills where crabbed in Resolve from the debayered RAW footage without a LUT applied, exported as .dpx and converted to sRGB .jpg in photoshop.





Does anybody has the same problem with the BMMCC?
Does anybody has an idea what the problem might be?
Does anybody knows how to fix this problem?

I was thinking about downgrading my BMMCC to an older firmware to see if the problem might be solved like this.
Does anybody knows if this is possible without the risk of causing other problems?

I appreciate any kind of help! Thank you very much!
Andi

Hot pixels are 1x1 pixel squares so your artifact don't looks like pixel, it looks more like dust particle in the light stream or some other external light source. Maybe some kind of insect?
I downgraded firmware many times without any problems.

Correct! This is definitely not a hot pixel issue. But since the flashing occurs always only for one frame and in different situations it is also not dust nor any other reflecting particles. I‘m pretty sure these are clusters of pixels and has something to do with the sensor.

Do you think downgrading the firmware is worth a try?

Do you or anybody else has an other idea what the problem might be or how to solve it?

Thanks!

mm looks different to the issue I was having. The only thing that I notice of mine is that the camera may be a frame or so too slow to cover up hotpixels when the pixel is put in and out of a high then low contrast area quickly. I think it's stresses the camera a bit.

Not sure what that is though, I guess the only way to really know if it's the firmware is to downgrade and have a check. As people have said it could be the lens, dust, etc, who knows. I haven't come across it though. Wish I could be of more help.

Thank you for the effort! The hotpixel-cover-up theory is interesting! Is this cover up function new in firmware 4.7.1? The only thing that not matches with my experience is, that the area where the pixels are flashing is not changing quickly from low to high contrast. The flashing occurs in constant contrast areas.

I‘m on the road for the next two days and will try a firmware downgrade, when I‘m back home.

In the meantime, more ideas, suggestions or ideally a solution, will be very apreciated!

Thank you!

Ryan Payne wrote:
The only thing of note was that I did find one or two pink pixels but it only for a second or so. it seems to be caused by the drastic change in colours going from brown/gold to black. So I assume there is a stuck pixel there and the fix for it is working to cover it up but me constantly moving it in and out of the black letter is giving it a hard time.

Look forward to see other people do better tests than mine to see if it's fixed or not.

I really want to do the update... because I often switch frame rates.
And I am using an external remote control which are able to change frame rates
without ghoing into the menu of the camera. But this will only work with the latest
update. 4.7.

But it seems like the fix is only a "cover up". hmmmm. Should I wait
for update. 4.7.2. Is the blackmagic Team aware of this?

same here...

Guys, try loading the new 4.9, which should give the latest version of 4.7.1x to the Micro Camera. I did the 4.7.1update, and am not seeing this issue at all. And this does not look like any stuck pixel I have ever seen. If you were shooting a tape based camera, I would say it was a tape artifact, not sensor or optical. As yiu said, an optical issue would show up in all the frames, unless the camera software was trying to hide it thinking it was a hot pixel. Interesting “coverup”theory.
Cheers

Andi Widmer wrote:The flashing occurs at random positions, at random times and at random size but always for one frame.

That sounds and looks like 'digital dust'.

From an arri engineer

looking at the image, zooming in... I tend to say it is not a dead pixel:
- only on one frame
- it is white

Therefore I lean towards the occurrence of "digital dust". That's high energy particles hitting the sensor (its source is natural or artificial radiation - depending on your location). Usually those look like white streaks since they tend to hit the sensor in a non-perpendicular manner; but its shape may vary: dots, lines, we even saw strange "curves". The location on the sensor/image is random and it occurs on one frame only.

https://www.arri.com/forum/viewtopic.php?f=46&t=104

You guys go crazy with your theories at times.

Not even the first time digital dust has been in a hot pixel thread here

viewtopic.php?f=2&t=13612&start=150#p115947

John Brawley wrote:Looks more like "digital dust". It's something I also see on Alexa's from time to time.

Never heard of a real reason for why they occur. One theory is cosmic radiation randomly hitting the sensor. Doesn't explain why I've never seen it till the last couple of years.

I've always found it happens when shooting ProRes but not RAW. Did you shoot Prores ?

JB

Yes, I agree with JB, some kind of interference (digital dust), works for me.
Cheers

Not a crazy theory at all!

Do you know that high flying airplanes use redundant electronics, like computers, to counteract the problem? They are hit by many more high energy particles than us (or our cameras) when we are on the ground and a fault could spell disaster.

But nevertheless radiation is everywhere, from cosmic sources, natural radiation from matter around us and from nuclear testing or disasters. Our photocells are small enough and their sensitivity is high enough to be influenced by radiation hitting at the wrong place.

Captain Hook wrote: "It's purpose is to minimize black balance/offset drift for the 4.6K sensor." That would have been my assumption too. To generate a full calibration for every single pixel would take much longer. Even a Red Epic Dragon needs several minutes doing it for just one setting, and you need more than one for different temperature conditions or exposure times.

Hey everybody!

Thank you for your interest and your suggestions for explanations of the pixel-dust phenomenon!

I checked all the linked threads and indeed, there are other reports of the same issue. But I couldn’t find neither a proved explanation (maybe it doesn’t exist) nor a solution for the phenomenon.

The cosmic radiation theory is interesting and everything that people reports, matches with my experience. The only thing that makes me doubt is, that I had pixel-dust at different places and different times in a row.

First time in Berlin at December 11 2017.
Second time in Vienna at December 16 2017.
Third time in Zurich at January 4 2018.

I made a sensor test without lens, only the dust cap on the camera. I tested the following camera settings:

raw_film_3200k_800iso_25fps_180shutter
raw_film_3200k_800iso_25fps_360shutter
raw_film_3200k_1600iso_25fps_180shutter
raw_film_3200k_1600iso_25fps_360shutter

raw-3:1_film_3200k_800iso_50fps_180shutter
raw-3:1_film_3200k_800iso_50fps_360shutter
raw-3:1_film_3200k_1600iso_50fps_180shutter
raw-3:1_film_3200k_1600iso_50fps_360shutter

Here is the edited footage. You have to watch very carefully to see the frames, when the pixel-dust flashes.


Password: pixel-dust

Pixel-dust is visible on all the RAW tests but only on the RAW 3:1 test with 1600iso/360shutter. This maybe coincidence or the camera is more stressed when recording RAW and RAW 3:1 with 1600iso/360shutter. In this case, Ryan Payne’s cover-up theory maybe appropriate. I don’t know…

If somebody experienced has the passion to take a closer look at the issue, I’d be very glad to provide some .dng files. Unfortunately I couldn't figure out how to embed them in this message.

Still looking for an explanation and a solution for the issue.

Thank you!

Well, I think the radiation theory might hold.
But I'm not bringing my camera (or myself) into the Fukushima area to verify it!

Interesting. Radioactive pollution spread over Europe was detected over that time. Wonder if BMMCC can be Geiger counter. http://www.telegraph.co.uk/news/2017/11 ... -accident/

Beside magic particles on your video there is one real hot pixel in the bottom center. Anyway capture pure black frame is not an easy task for any digital camera.

Radiation damaging sensors is a real thing.

Sensors also do degrade over time. Some thinking is that it's cosmic radiation hits. The "digital dust" is something I occasionally see on Blackmagic, I honestly see it more on Alexa.

It's not the "radioactive" things like nuclear power plants, but just plain old ordinary background radiation that the planet's atmosphere MOSTLY shields us from down here on the surface.

It's also why many camera rental companies prefer to ship digital cameras via road. When you fly you increase your exposure to background radiation dramatically.

It seems like from what Kris was saying earlier in this thread it may be for other reasons, but don't laugh off the radiation theory. It's real.

Discussed here
viewtopic.php?f=2&t=64560&p=367375#p365507

and
in summary
https://ntrs.nasa.gov/archive/nasa/casi ... 022613.pdf
https://www.nasa.gov/mission_pages/stat ... s/974.html
https://www.nasa.gov/mission_pages/stat ... s/124.html
http://www.tested.com/science/space/455 ... ors-space/

JB

Yes, the “cosmic Rays”are actually high energy particles, and the higher you go, the more likely you are to be hit by them. So, the phenomenon issue is both real, and can be measured. There are many type of particles, and it seems the ones that have a electrically charged cause the damage. Some un-charged particles can even penetrate the earth, but this type normally does not bother us, or the sensors. The charged particles can interact with the sensor, causing artifacts we can seee. You can also see the effect on film, if the charged high energy particles are numerous enough.
Cheers