[I figured this specific topic was worth spinning off from the main comparison thread]
UPDATE: The first set of pictures were taken with the 0928 Firmware ... but the Gain controls were changed from what we are used too. Per @EMPIRETECANDY, consider rolling back to 0731 Firmware.
I just got the T54PRO-ZE and wanted to compare the "basic" sensor/lens/processing of it versus the 5442-S3 under low-light conditions.
First, there are people on this forum waayyy more knowledgeable than me (looking at you @steve1225 ... and others) and there is more to cameras than just seeing what type of image one can get when there's aren't a whole lotta photons. But here's my first WAG at trying to answer the specific question if the T54PRO-ZE has improved low-light capability (seems like it does!) and I welcome candid feedback.
I'd also love to see some similar side-by-side comparisons from others ... and please limit that just to low-light performance for this thread.
Note that this is a pretty dim scene (several hours after sunset and it was cloudy/raining, so no moonlight, etc.) so yes, I'm using fairly ridiculous parameters. Specifically, the Exposure was Custom with Shutter at 0-100msec (yep, that means 1/10s shutter speed!), a gain of 100%(!), Iris at 100%, 3D NR of 50, and 2D NR of 25.
Yes, if you setup your cameras using these setting, be sure to post a sign telling any robbers to walk veerrryyyy slowly since otherwise about the only motion you are going to capture with that is ghosts! ;-)
Here's two images from the same time - output is from the same home-grown Perl script which uses ffmpeg to connect via RTSP, and from the stream generates a 1920x1080 HD image with minimal processing besides adding the custom tag and date/time stamp in the top right. NOTE: the 1920x1080 images don't show inline (too big?), so these are resized to 960x540 ... and the 1920x1080 are attached in the next post.
A couple of quick observations when I was playing around with this - specific to this scene, but maybe more broadly.
When you increase the gain on the 5442-S3 from 90 to 100%, the image really falls apart ... so I think internally there is a big jump in the ISO which is pushing the sensor way beyond it's limits. The T54PRO-ZE didn't seem as dramatic.
Pushing the 2D NR level on the 5442-S3 from 25 to 50% did clean things up the noise a bit ... but resulted in the (expected) loss of detail. On the T54PRO-ZE, pushing from 25% to 50% didn't seem to make much difference.
Which kinda suggests to to me that (at least for this scene), the 5442-S3 is at it's limit, whereas the T54PRO-ZE still has some headroom before it falls apart.
But HEY, can we get the image even better/brighter for this application ... and (DUH!) we can!!!
The camera lens is zoomed in about 2/3rd's the way to capture that scene (1650 on a scale that goes to ~2400) ... and it's not uncommon that a vari-focal lens will NOT be constant aperture ... since this requires bigger/heavier lens. I.e. this is why my 70-200/F2.8 camera lens is BIG ... because it's 2.8 at 200mm. Now for a constant aperture lens, you want to put as many pixels on target, since the light gathering is same. And if you end up resizing, you get some noise/quality benefits.
But then I realized (DUH!) that "I could have had a V-8!" ... since it's possible that if I zoom out the lens (getting a bigger aperture), the increased light gathering may more than offset taking a 1920x1080 crop versus resizing the zoomed in 2688x1520 image. I ended up going from 1650 to 550 on the zoom ... and the 1920x1080 crop of the wider image is about the same FOV.
Here's what that look like. And pulling both of the T54PRO-ZE images into Photoshop and using the eyedropper tool and then pushing the exposure, I'd estimate there's about 3/4 of a stop difference. Too bad Dahua doesn't publish a graph showing the aperture versus focal length as I'd love to see if I'm in the ballpark.
BTW, I'm still trying to figure this out, but I think(?) there's something a bit "more funky" about the T54PRO-ZE, since when I use ffmpeg/RTSP (or the snapshot.cgi API call), it appears to be pushing the blacks (and maybe clipping the whites) so the JPEG values are almost all from16-235 rather than 0-255. I've seen this before per this thread and since the color space is compressed, the image looks a bit hazy (more noticeable in images like this) ... plus if I pull it into Photshop, you can "see" this using the Levels tool ... and using the threshold, I can see almost nothing below 16 ... even though there is plenty of dark there.
What's confusing is that you don't see this when using the Snapshot button on the web interface. Incidentally, this generates a (huge) PNG file ... which if I pull the 8,392KByte file into Photoshop, save as a high quality JPEG, it's 920KBytes (and there's barely any difference between them) ... be nice if Dahua gave that as an option. But this has the "full" color space and it visually looked better.
What doubly confusing is ffmpeg reports that it is "yuvj420p (0-255)" ... not "youv420p (16-235)" per this output "Stream #0:0: Video: h264 (High), yuvj420p(pc, smpte170m, progressive), 2688x1520, 6 fps" ... so I'm not sure what is going on - maybe something intermediate in the pipeline?
But I remember @steve1225 saying something about how the internal processing is different with these camera and you can get the "old" way back by setting WDR>50%. That makes the image look like crap ... but then I tried setting HLC to one (the smallest value) and that seemed to fix it - ditto if I turn BLC on, even if I pick the tiniest custom area.
So I'm still trying to figure this one out - could be buffoonary on my part, but seems like something goofy in the image processing pipeline. Related is I'm not impressed by the internal resizing algorithm if you pick a non-native resolution ... wondering if the code has a "Save As" with low quality. And yes, even though it shouldn't affect the RTSP stream, I have Snapshot on the web config turned all the way up to six.
UPDATE: The first set of pictures were taken with the 0928 Firmware ... but the Gain controls were changed from what we are used too. Per @EMPIRETECANDY, consider rolling back to 0731 Firmware.
I just got the T54PRO-ZE and wanted to compare the "basic" sensor/lens/processing of it versus the 5442-S3 under low-light conditions.
First, there are people on this forum waayyy more knowledgeable than me (looking at you @steve1225 ... and others) and there is more to cameras than just seeing what type of image one can get when there's aren't a whole lotta photons. But here's my first WAG at trying to answer the specific question if the T54PRO-ZE has improved low-light capability (seems like it does!) and I welcome candid feedback.
I'd also love to see some similar side-by-side comparisons from others ... and please limit that just to low-light performance for this thread.
Note that this is a pretty dim scene (several hours after sunset and it was cloudy/raining, so no moonlight, etc.) so yes, I'm using fairly ridiculous parameters. Specifically, the Exposure was Custom with Shutter at 0-100msec (yep, that means 1/10s shutter speed!), a gain of 100%(!), Iris at 100%, 3D NR of 50, and 2D NR of 25.
Yes, if you setup your cameras using these setting, be sure to post a sign telling any robbers to walk veerrryyyy slowly since otherwise about the only motion you are going to capture with that is ghosts! ;-)
Here's two images from the same time - output is from the same home-grown Perl script which uses ffmpeg to connect via RTSP, and from the stream generates a 1920x1080 HD image with minimal processing besides adding the custom tag and date/time stamp in the top right. NOTE: the 1920x1080 images don't show inline (too big?), so these are resized to 960x540 ... and the 1920x1080 are attached in the next post.
A couple of quick observations when I was playing around with this - specific to this scene, but maybe more broadly.
When you increase the gain on the 5442-S3 from 90 to 100%, the image really falls apart ... so I think internally there is a big jump in the ISO which is pushing the sensor way beyond it's limits. The T54PRO-ZE didn't seem as dramatic.
Pushing the 2D NR level on the 5442-S3 from 25 to 50% did clean things up the noise a bit ... but resulted in the (expected) loss of detail. On the T54PRO-ZE, pushing from 25% to 50% didn't seem to make much difference.
Which kinda suggests to to me that (at least for this scene), the 5442-S3 is at it's limit, whereas the T54PRO-ZE still has some headroom before it falls apart.
But HEY, can we get the image even better/brighter for this application ... and (DUH!) we can!!!
The camera lens is zoomed in about 2/3rd's the way to capture that scene (1650 on a scale that goes to ~2400) ... and it's not uncommon that a vari-focal lens will NOT be constant aperture ... since this requires bigger/heavier lens. I.e. this is why my 70-200/F2.8 camera lens is BIG ... because it's 2.8 at 200mm. Now for a constant aperture lens, you want to put as many pixels on target, since the light gathering is same. And if you end up resizing, you get some noise/quality benefits.
But then I realized (DUH!) that "I could have had a V-8!" ... since it's possible that if I zoom out the lens (getting a bigger aperture), the increased light gathering may more than offset taking a 1920x1080 crop versus resizing the zoomed in 2688x1520 image. I ended up going from 1650 to 550 on the zoom ... and the 1920x1080 crop of the wider image is about the same FOV.
Here's what that look like. And pulling both of the T54PRO-ZE images into Photoshop and using the eyedropper tool and then pushing the exposure, I'd estimate there's about 3/4 of a stop difference. Too bad Dahua doesn't publish a graph showing the aperture versus focal length as I'd love to see if I'm in the ballpark.
BTW, I'm still trying to figure this out, but I think(?) there's something a bit "more funky" about the T54PRO-ZE, since when I use ffmpeg/RTSP (or the snapshot.cgi API call), it appears to be pushing the blacks (and maybe clipping the whites) so the JPEG values are almost all from16-235 rather than 0-255. I've seen this before per this thread and since the color space is compressed, the image looks a bit hazy (more noticeable in images like this) ... plus if I pull it into Photshop, you can "see" this using the Levels tool ... and using the threshold, I can see almost nothing below 16 ... even though there is plenty of dark there.
What's confusing is that you don't see this when using the Snapshot button on the web interface. Incidentally, this generates a (huge) PNG file ... which if I pull the 8,392KByte file into Photoshop, save as a high quality JPEG, it's 920KBytes (and there's barely any difference between them) ... be nice if Dahua gave that as an option. But this has the "full" color space and it visually looked better.
What doubly confusing is ffmpeg reports that it is "yuvj420p (0-255)" ... not "youv420p (16-235)" per this output "Stream #0:0: Video: h264 (High), yuvj420p(pc, smpte170m, progressive), 2688x1520, 6 fps" ... so I'm not sure what is going on - maybe something intermediate in the pipeline?
But I remember @steve1225 saying something about how the internal processing is different with these camera and you can get the "old" way back by setting WDR>50%. That makes the image look like crap ... but then I tried setting HLC to one (the smallest value) and that seemed to fix it - ditto if I turn BLC on, even if I pick the tiniest custom area.
So I'm still trying to figure this one out - could be buffoonary on my part, but seems like something goofy in the image processing pipeline. Related is I'm not impressed by the internal resizing algorithm if you pick a non-native resolution ... wondering if the code has a "Save As" with low quality. And yes, even though it shouldn't affect the RTSP stream, I have Snapshot on the web config turned all the way up to six.
Last edited:
