SMD 3.0 dahua

All

Quick update from my post above. I believe after a **** (insert chosen word) ton of testing I've found 2 major underlying bugs that are causing the SmartIR issues under certain conditions. I captured a lot of video last night to test this theory with pro equipment in the mix too and once i've edited and put my notes together will post here over the next day or 2. My plan being to take these to Dahua (will be alerting @EMPIRETECANDY too so can assist in driving) to have them looked into as Dahua were unable to pinpoint any issues yet even though these problems absolutely do exist. I will then (after posting my findings and video here) move onto different HW revisions for verification testing there too. However, with what I've tested so far, 1 of the bugs seems to be in multiple codebases therefore hopefully once we get this addressed, regression testing can take place on future FW releases and many HW platforms (running SmartIR) will benefit from these findings.

More to come
 
I had a cat get ID'd as a human overnight. The fox didn't even get recognized.
 
I had a cat get ID'd as a human overnight. The fox didn't even get recognized.
My 5442 SMD 2.0 alerts me almost every time a cat comes strolling by at 3am. Which is rather frequent. I have to keep the alerts up due to my tire slashing issue (nothing since Jan 14th but keeping on my toes). I run 24/7 color. Am hoping SMD3.0 at least fixes the human AI vs animals, in my case. Else, I'll have to rely on Deepstack AI (not fun to do in rainstorm or snowstorm as kicks CPU waaaaaay up). Maybe the algorithm thinks the cat + shadow from cat = The Ring girl crawling on the ground...which is somewhat human.
EntranceLow x23 2021-05-13 09.13.55.565 PM.jpg
 
@Holbs I don't have enough light to run full color at night so everything is in B&W. I've been tweaking the cameras trying to get DS to recognize things. I guess seeing a cat as a human is actually some sort of progress.
 
@Holbs I don't have enough light to run full color at night so everything is in B&W. I've been tweaking the cameras trying to get DS to recognize things. I guess seeing a cat as a human is actually some sort of progress.
I put the use of Deepstack AI (before it was included into Blue Iris) on hold when @wittaj converted me to using Dahua Human AI (saves on CPU). I considered Deepstack 85% fantastic, Dahua AI 95% fantastic. Both have issues at night due to .... well, being night and a mostly dark wooden & blacktop background. Hence, my backup enhancement of using the Bosch Tritech pet immunity PIR (which works fantastic...though does trigger on passing cars for some reason).
 
@Holbs I don't have enough light to run full color at night so everything is in B&W. I've been tweaking the cameras trying to get DS to recognize things. I guess seeing a cat as a human is actually some sort of progress.
have you thought of flood lights? that is what you see in my picture. This flood light is on from Dusk to Dawn. Once I feel more...ahem....safer, I'll swap it back to motion, or better yet will integrate into Home Assistant/DSC PIR alarm/Blue Iris triggered alerts (all via MQTT).
 
We're in the hinter lands, countryside, and neither the neighbors or we would like lights on all night. A few people have motion based floods but I view that as a toy more than anything else, plus we're too cheap to want to run even LED floods all night. I've already got them all around the house and could use dusk/dawn photocell or timers but it makes the place look like a prison.
 
** WARNING - DETAILED POST & VIDEO INCOMING **

Intro


I believe I’ve cracked the issue with SmartIR and also believe this may have ramifications across the SmartIR FW’s for many Dahua cams as this is at code level and relating to algorithms / logic processing by this feature in certain situations and configurations.​
I wanted to finally get to the bottom of it especially since 05-06 exhibits the same issues reported before. So, I decided to sink some (ok a lot of) time into testing this thoroughly. How thoroughly ? Well using multiple cams setup through various NLE’s (FCP and an AVID Artist DnxHR + an IQ) with an in-between set of monitors, namely 4K Sony Tri-Masters so I could look at every function of the camera from resolution based changes affecting image to monitoring even the slightest change in output scopes (Tri-Masters have built in waveform monitoring and using the NLE’s for a secondary view to trap). I monitored outputs from the cams into the Tri-Masters and then through NLE’s out to Tri-Masters. I also threw a couple of Atomos Shoguns in the mix for an extra layer of replication testing. I wanted to be able to see what if anything was changing when SmartIR was used vs other functions that would then allow me to pinpoint where to look from a codebase perspective.​
The outcome of all this work is that I believe I now know what is happening with these Dahua FW’s and SmartIR. I absolutely have uncovered 2 bugs and while I believe 1 of them (Bug #1) may be fixed in later HW (due to the way FW code addresses it, but will be testing this later this week) that there are still situations and combinations that will cause this issue to return (therefore needs fixing). On the 2nd bug (Bug #2), this appears more deep rooted in code and definitely goes back further. This doesn’t look like its ever been addressed and therefore has wider implications to the SmartIR feature on cams WHEN used with other functions. I even tested on 11-23 to see how prevalent this was and guess what…….the issue was present.​
I do hope you’ll take time to watch the video, its detailed (primarily so Dahua should have everything it needs) but is timestamped and I hope it helps all understand the issues here. So lets jump into the video then pick back up with summary below:​


Video Link (Uploaded In Native Res. So Choose 1440p in YT)




Ok You’re Back (or maybe you didn’t leave), Lets Get To The Summary

2 bugs found in this testing and both are in FW code, i.e. need to be fixed by Dahua engineers:
  • Bug #1 - HLC seemingly enabled under the hood in 05/06 FW. Doesn’t show in GUI as enabled but testing and scope work shows that it appears to be the case

  • Bug #2 - Backlight programs and SmartIR do not work correctly in conjunction with each other in the current SmartIR implementation. Backlight program takes precedent when both are being used and SmartIR algorithms / logic are not processing the image. This leads to incorrect or non existent reading of FOV which in turn means no adjustments are made to IR strength, exposure range, exposure compensation and therefore leads to IR washout of targets.

I’ve included a few output scope caps here for you as well so you can see the bloom I noticed in 05-06 vs 11-23 straight after upgrade and led me on the path to test :). Its worth pointing out (as hopefully you’ll see from the comparison caps below) that 11-23 still handles SmartIR slightly better than 05-06 when only SmartIR is used BUT of course this is somewhat beside the point because there are other issues at hand.

Scope Comparisons

Front Facing Comparison
Straight After Upgrade - SmartIR Only, No backlight Programs (however in the case of 05-06, none showing but testing shows different story)
20-11-23 (Left) vs 21-05-06 (Right)

11-23 Image - Straight After Upgrade (Front Facing).jpg 05-06 - Straight After Upgrade (Front Facing).jpg


Side Comparison
Straight After Upgrade - SmartIR Only, No backlight Programs (however in the case of 05-06, none showing but again testing shows different story)
20-11-23 (Left) vs 21-05-06 (Right)

11-23 Image - Straight After Upgrade (Side Facing).jpg 05-06 - Straight After Upgrade (Side Facing).jpg

Front Facing Comparison
SmartIR Only (05-06 FW with HLC = OFF)
20-11-23 (Left) vs 21-05-06 (Right)

11-23 Image - Straight After Upgrade (Side Facing).jpg 05-06 - SmartIR Only.jpg

Side Facing 05-06 with SmartIR and HLC = On

05-06 - SmartIR + HLC (Side Facing).jpg


How To Fix - Dahua

  • Bug #1 - Appears limited to 05/06 FW and may be tied to how this FW addresses older HW revision (will be testing on new HW revs soon)

  • Bug #2 - This is an issue with SmartIR algorithms and how SmartIR works when Backlight programs are enabled. This is a wider, more deep rooted issue in codebases. This needs to be reviewed and algorithms / logic re-written to ensure that regardless of program, the camera assesses IR needs in FOV (using SmartIR) and adjusts for targets FIRST, BEFORE a Backlight program is assessed. Then have the algorithm work in conjunction with the Backlight program to apply 1 or both logic values (or ideally a balance of them) to ensure that no part of the scene, whether lit with visible or non-visible light is washed out / over exposed

How To Fix - End User - Bug #2

So how can you mitigate as an end user in the interim ? Well a couple of ways:
  1. Don’t use Backlight programs with SmartIR currently ;) (I know not really an option but I had to list for completeness)
  2. If you do have a need to use both (which is certainly understandable and to be honest I recommend both in a number of situations) then you can use Exposure Compensation set to around 12 - 14 to ensure some manual compensation occurs for now. Just understand this will darken your overall image. I also want to be clear, this is not the fix I believe Dahua should use as it really is just compensating for algorithms not working and SmartIR not processing the scene BUT this is an option for end users until a fix comes

I know that was a lot to digest in the video but hopefully makes sense for all here and you found it useful.

@EMPIRETECANDY, lets you and I ensure Dahua is able to review this newer video too and is able to start working on fixing.

Equipment Used For Testing (for those interested)
  • IPC-T5442T-ZE Vari Turret
  • IPC-B5442E-ZE Bullet Cam
  • IPC-HFW5241E-Z12E (issue with targets up close but distanced targets such as in LPR are ok due to IR fall off etc as expected) - Still an issue but depending on use may not see it as I state here
  • 3 x Dahua PTZ’s
  • Sony Tri Master PVM2400’s
  • Atomos Shogun
  • Final Cut Pro
  • Avid DnxHR + DnxIQ
  • Crap ton of cables and adapters

Will cross post in the FW thread for awareness there too
 
** WARNING - DETAILED POST & VIDEO INCOMING **

Intro


I believe I’ve cracked the issue with SmartIR and also believe this may have ramifications across the SmartIR FW’s for many Dahua cams as this is at code level and relating to algorithms / logic processing by this feature in certain situations and configurations.​
I wanted to finally get to the bottom of it especially since 05-06 exhibits the same issues reported before. So, I decided to sink some (ok a lot of) time into testing this thoroughly. How thoroughly ? Well using multiple cams setup through various NLE’s (FCP and an AVID Artist DnxHR + an IQ) with an in-between set of monitors, namely 4K Sony Tri-Masters so I could look at every function of the camera from resolution based changes affecting image to monitoring even the slightest change in output scopes (Tri-Masters have built in waveform monitoring and using the NLE’s for a secondary view to trap). I monitored outputs from the cams into the Tri-Masters and then through NLE’s out to Tri-Masters. I also threw a couple of Atomos Shoguns in the mix for an extra layer of replication testing. I wanted to be able to see what if anything was changing when SmartIR was used vs other functions that would then allow me to pinpoint where to look from a codebase perspective.​
The outcome of all this work is that I believe I now know what is happening with these Dahua FW’s and SmartIR. I absolutely have uncovered 2 bugs and while I believe 1 of them (Bug #1) may be fixed in later HW (due to the way FW code addresses it, but will be testing this later this week) that there are still situations and combinations that will cause this issue to return (therefore needs fixing). On the 2nd bug (Bug #2), this appears more deep rooted in code and definitely goes back further. This doesn’t look like its ever been addressed and therefore has wider implications to the SmartIR feature on cams WHEN used with other functions. I even tested on 11-23 to see how prevalent this was and guess what…….the issue was present.​
I do hope you’ll take time to watch the video, its detailed (primarily so Dahua should have everything it needs) but is timestamped and I hope it helps all understand the issues here. So lets jump into the video then pick back up with summary below:​


Video Link (Uploaded In Native Res. So Choose 1440p in YT)




Ok You’re Back (or maybe you didn’t leave), Lets Get To The Summary

2 bugs found in this testing and both are in FW code, i.e. need to be fixed by Dahua engineers:
  • Bug #1 - HLC seemingly enabled under the hood in 05/06 FW. Doesn’t show in GUI as enabled but testing and scope work shows that it appears to be the case

  • Bug #2 - Backlight programs and SmartIR do not work correctly in conjunction with each other in the current SmartIR implementation. Backlight program takes precedent when both are being used and SmartIR algorithms / logic are not processing the image. This leads to incorrect or non existent reading of FOV which in turn means no adjustments are made to IR strength, exposure range, exposure compensation and therefore leads to IR washout of targets.

I’ve included a few output scope caps here for you as well so you can see the bloom I noticed in 05-06 vs 11-23 straight after upgrade and led me on the path to test :). Its worth pointing out (as hopefully you’ll see from the comparison caps below) that 11-23 still handles SmartIR slightly better than 05-06 when only SmartIR is used BUT of course this is somewhat beside the point because there are other issues at hand.

Scope Comparisons

Front Facing Comparison
Straight After Upgrade - SmartIR Only, No backlight Programs (however in the case of 05-06, none showing but testing shows different story)
20-11-23 (Left) vs 21-05-06 (Right)



Side Comparison
Straight After Upgrade - SmartIR Only, No backlight Programs (however in the case of 05-06, none showing but again testing shows different story)
20-11-23 (Left) vs 21-05-06 (Right)


Front Facing Comparison
SmartIR Only (05-06 FW with HLC = OFF)
20-11-23 (Left) vs 21-05-06 (Right)


Side Facing 05-06 with SmartIR and HLC = On



How To Fix - Dahua

  • Bug #1 - Appears limited to 05/06 FW and may be tied to how this FW addresses older HW revision (will be testing on new HW revs soon)

  • Bug #2 - This is an issue with SmartIR algorithms and how SmartIR works when Backlight programs are enabled. This is a wider, more deep rooted issue in codebases. This needs to be reviewed and algorithms / logic re-written to ensure that regardless of program, the camera assesses IR needs in FOV (using SmartIR) and adjusts for targets FIRST, BEFORE a Backlight program is assessed. Then have the algorithm work in conjunction with the Backlight program to apply 1 or both logic values (or ideally a balance of them) to ensure that no part of the scene, whether lit with visible or non-visible light is washed out / over exposed

How To Fix - End User - Bug #2

So how can you mitigate as an end user in the interim ? Well a couple of ways:
  1. Don’t use Backlight programs with SmartIR currently ;) (I know not really an option but I had to list for completeness)
  2. If you do have a need to use both (which is certainly understandable and to be honest I recommend both in a number of situations) then you can use Exposure Compensation set to around 12 - 14 to ensure some manual compensation occurs for now. Just understand this will darken your overall image. I also want to be clear, this is not the fix I believe Dahua should use as it really is just compensating for algorithms not working and SmartIR not processing the scene BUT this is an option for end users until a fix comes

I know that was a lot to digest in the video but hopefully makes sense for all here and you found it useful.

@EMPIRETECANDY, lets you and I ensure Dahua is able to review this newer video too and is able to start working on fixing.

Equipment Used For Testing (for those interested)
  • IPC-T5442T-ZE Vari Turret
  • IPC-B5442E-ZE Bullet Cam
  • IPC-HFW5241E-Z12E (issue with targets up close but distanced targets such as in LPR are ok due to IR fall off etc as expected) - Still an issue but depending on use may not see it as I state here
  • 3 x Dahua PTZ’s
  • Sony Tri Master PVM2400’s
  • Atomos Shogun
  • Final Cut Pro
  • Avid DnxHR + DnxIQ
  • Crap ton of cables and adapters

Will cross post in the FW thread for awareness there too

Outstanding job @Wildcat_1 .
Thank you for your continued efforts on this.
 
Very informative post, thanks.

Just wondering, after you switch HLC on and then back off to actually disable it does a restart of the cam keep it disabled or does it revert to being silently enabled?
 
Very informative post, thanks.

Just wondering, after you switch HLC on and then back off to actually disable it does a restart of the cam keep it disabled or does it revert to being silently enabled?

@IAmATeaf it looks to happen just once, after you install / upgrade to 05-06 then once you follow the directions I mentioned (turn on...save....turn off....save) that resolves it UNTIL next time you upgrade to 05-06 (should you do so). What is weird about Bug #1 is that it survives a factory reset in between. Now again, Bug #1 may be tied to older HW revisions of the same cam (and looks to have been introduced in 05-06), I will be testing on a couple of newer revs too but Bug #2 is prevalent and deep rooted not just on this FW but previous releases and as I said even across other FW codebases. Therefore that one needs priority attention across the board IMO.

HTH
 
** WARNING - DETAILED POST & VIDEO INCOMING **

Intro


I believe I’ve cracked the issue with SmartIR and also believe this may have ramifications across the SmartIR FW’s for many Dahua cams as this is at code level and relating to algorithms / logic processing by this feature in certain situations and configurations.​
I wanted to finally get to the bottom of it especially since 05-06 exhibits the same issues reported before. So, I decided to sink some (ok a lot of) time into testing this thoroughly. How thoroughly ? Well using multiple cams setup through various NLE’s (FCP and an AVID Artist DnxHR + an IQ) with an in-between set of monitors, namely 4K Sony Tri-Masters so I could look at every function of the camera from resolution based changes affecting image to monitoring even the slightest change in output scopes (Tri-Masters have built in waveform monitoring and using the NLE’s for a secondary view to trap). I monitored outputs from the cams into the Tri-Masters and then through NLE’s out to Tri-Masters. I also threw a couple of Atomos Shoguns in the mix for an extra layer of replication testing. I wanted to be able to see what if anything was changing when SmartIR was used vs other functions that would then allow me to pinpoint where to look from a codebase perspective.​
The outcome of all this work is that I believe I now know what is happening with these Dahua FW’s and SmartIR. I absolutely have uncovered 2 bugs and while I believe 1 of them (Bug #1) may be fixed in later HW (due to the way FW code addresses it, but will be testing this later this week) that there are still situations and combinations that will cause this issue to return (therefore needs fixing). On the 2nd bug (Bug #2), this appears more deep rooted in code and definitely goes back further. This doesn’t look like its ever been addressed and therefore has wider implications to the SmartIR feature on cams WHEN used with other functions. I even tested on 11-23 to see how prevalent this was and guess what…….the issue was present.​
I do hope you’ll take time to watch the video, its detailed (primarily so Dahua should have everything it needs) but is timestamped and I hope it helps all understand the issues here. So lets jump into the video then pick back up with summary below:​
Gots to buy you a big fluffy white bunny suit for more in depth testing
 

Attachments

  • mens-easter-bunny-costume_13757964.jpg
    mens-easter-bunny-costume_13757964.jpg
    105.7 KB · Views: 7
So I have two cameras setup side by side right now. They are:

IPC-T5442TM-AS running 21-05-06 FIrmware
IPC-T5442TM-AS-LED running 20-12-03 Firmware

Both are setup the exact same. IVS Rule using an Intrusion, Enter/Exit & Appear. Human/Vehicle detection is on both, the rule takes up almost the entire screen (essentially Enter/Exit is useless in this scenario, just counting on Appears), and with the max size being the entire scene, and min size being 0x0. Global setup has Anti-Disturb Engine set to On, and Sensitivity set to 5 on both.

First test I walked out of my house, which puts me about a 1/4 of the way into the scene, about 140 feet away from the cameras. I walked towards the cameras, then turned when I got about 30 feet away, to see when both cams picked me up.

21-05-06 Firmware:

5442TM Tester_IPC_main_20210517220208_@40.jpg

20-12-03 Firmware:

5442TM-LED Tester_IPC-T5442TM-AS-LED_main_20210517210154_@41.jpg

The 20-12-03 firmware picks me up much, much sooner. The 21-05-06 didn't pick me up until I was pretty much nicely centered in the screen, and turning sideways to exit to the left of the image.

I then walked in from the left side of the image, following my tracks back to the house:

21-05-06

Did not register at all

20-12-03
5442TM-LED Tester_IPC-T5442TM-AS-LED_main_20210517210311_@41.jpg

Here 20-12-03 definitively wins, as 21-05-06 chose not to even participate.

Then I decided to repeat the test again, to see if it was a fluke or not.

21-05-06
5442TM Tester_IPC_main_20210517220430_@40.jpg

20-12-03
5442TM-LED Tester_IPC-T5442TM-AS-LED_main_20210517210412_@41.jpg

21-05-06:
5442TM Tester_IPC_main_20210517220516_@40.jpg
20-12-03:
5442TM-LED Tester_IPC-T5442TM-AS-LED_main_20210517210519_@41.jpg

On the second test, my approaching the camera test yielded very similar results, the SMD2.0 firmware picked me up right away, with SMD3.0 firmware waiting until I was very close to the camera. When I entered the scene from the left side this time, they both picked me up, and did so fairly quickly.

Also, if you are using the time for comparison, the LED version is 4 seconds ahead of the non-LED Version. The non-led version is also out by an hour they should both be reading 21:XX;XX.
 
I should add, I have yet to see one of my dogs trigger it. I only setup the IVS rules right before the test above, but I did call my dogs through the scene a couple of times to see if they could trigger any motion. I have had dogs in the past trigger IVS rules. I didn't get a single trigger though on either camera. I will have to do some more testing hopefully tomorrow to see if I can get the new firmware triggering as fast as the old one. As for now though, I don't know if I'd be comfortable relying on SMD3.0 to trigger IVS alerts.
 
@cd36 - any chance you have SD cards in those cameras and could do the same test with IVS rules and then show pics with the IVS rules on showing the first time the box turned red?

Many of us experienced significant lag with the 3.0 firmware, but your setup of two cameras basically side-by-side would be a great test to show those differences.
 
@cd36 - any chance you have SD cards in those cameras and could do the same test with IVS rules and then show pics with the IVS rules on showing the first time the box turned red?

Many of us experienced significant lag with the 3.0 firmware, but your setup of two cameras basically side-by-side would be a great test to show those differences.

Yes, I do have SD Cards in both cameras. Those screen grabs are from the exact time the box turned red on me when replaying the recording. I couldn't do show them in an exact side by side comparison, due to the time being an hour out on one (I had just set the time, but it must have jumped on me when I changed time zone or DST settings and I didn't notice).

When I did the "Visitor Picture" from SmartPSS on the recording, of course it takes out the IVS Rule information. I can reset the times to be the same, and then do a side by side screen capture to show you the IVS rules in action, but that is essentially what is happening with the pictures above.