48 / 180 = 0.267
)1800 / 4096 = 0.439
)I had to find the control to adjust the aspect ratio on the Hikvision to get it to look decent, Not having the Dahua to test with I would bet it has the same control also so you can get the correct aspect for the image size, Kind of had to hunt for it If I remember correct.I like the physical dimensions of the Dahua turret compared to the Hik/Annke.
But it has an unexplained problem. The video it produces is not nearly wide enough for the field of view, and it shows in the form of fairly severe aspect ratio distortion.
It is pretty obvious that this will be a problem just looking at the specs. The video's aspect ratio is barely any wider than a standard 16:9 camera, yet the field of view is about double the width.
Here are some samples from Andy that he shared a few pages ago. I've cropped a few pieces.
For a baseline, this is the "4K-T 1/1.2CMOS" (a standard 16:9 camera):
View attachment 145228 View attachment 145230 View attachment 145233
These are from the "4K 180" daylight pic:
View attachment 145229 View attachment 145231 View attachment 145232 View attachment 145234
See the problem? Things appear unnaturally tall. It is not just a display choice as is weirdly common in the CCTV industry. This is actually a problem in the source video. A little simple math done on the specs shows why this is happening.
Based on the specified field of view, 180° horizontal and 48° vertical, the height is about 27% of the width. (48 / 180 = 0.267
)
The video resolution actually produced by the camera is not even close to matching this. The video resolution is 4096x1800, so the height of the image is about 44% of its width. (1800 / 4096 = 0.439
)
27% is a long way from 44%, and that is why the distortion is so obvious. This camera should be producing a much wider image, given its field of view. I wonder if this is one of the "bugs" noted by @Wildcat_1 when he was preparing to review the Dahua 180° bullet? Anyway now that I've noticed it, I cannot un-see it.
Compare to the Annke/Hikvision dual-4MP cam. Its advertised FOV is 180° horizontal and 44° vertical, so the height is 24% of the width, and the video resolution is 5120x1440 so the height is 28% of the width. These numbers are much closer together, and this is why the Annke images shared earlier in this thread don't have a noticeable amount of stretching compared to the Dahua cam.
Some distortion is to be expected because they have to stitch together video from two different sensors and make it look good. But right now it is looking like Hikvision did a much better job of it. Hikvision's video is actually 32:9 which is exactly what you would expect from combining two 16:9 sensors. Dahua's aspect ratio is 20.5:9.
Just thinking out loud here, but it would be ideal if product discussions about Dahua / Empiretech dual cameras was in a separate discussion. Rather than here, in a Annke product discussion. Mostly because it will be easier to find the info if it's not buried here. Plus would return the OP's subject back to the Annke cam.
BTW, I definitely will be getting the EmpireTech 180 turret if the reviews are good. And CCTVcam's proposal would be ideal for my front porch if the form factor was low profile.
- Thomas
Interesting. That is such a weird set of resolutions. 2880 * 1264 is very nearly the same aspect ratio as 4096 * 1800 and 3840 * 1680. Only 3840 * 1080 is a 32:9 aspect ratio and it is substantially lower res than the Annke/Hikvision cam.
That happened with the Annke cam?I picked up a couple of these cams for two different systems that run Blue Iris. My CPU usage jumped about 25 percent on each system after adding the cameras. The mainstream streams at about 1100kps, about 10 times what my 5442s stream. I use direct-to-disk and the other recommended Blue Iris CPU optimizations. Anyone else had this issue or found a way to reduce the CPU usage on these cams?
An interesting problem that I ran into was having the substream dropping out. It happened again yesterday with a camera I was moving, and this camera was on an NVR that has 7 cameras. It turned out that I had to put the camera on its own power supply instead of using the NVR POE power supply. Problem solved. So, if you are having substream problems look into separate power for the camera.
I picked up a couple of these cams for two different systems that run Blue Iris. My CPU usage jumped about 25 percent on each system after adding the cameras. The mainstream streams at about 1100kps, about 10 times what my 5442s stream. I use direct-to-disk and the other recommended Blue Iris CPU optimizations. Anyone else had this issue or found a way to reduce the CPU usage on these cams?
Are you sure that's not 11,000kbs? 1,100kbs woulld be very low.
I picked up a couple of these cams for two different systems that run Blue Iris. My CPU usage jumped about 25 percent on each system after adding the cameras. The mainstream streams at about 1100kps, about 10 times what my 5442s stream. I use direct-to-disk and the other recommended Blue Iris CPU optimizations. Anyone else had this issue or found a way to reduce the CPU usage on these cams?
Yep, both main and sub seem to be working fine. Mainstream averages about 1150kps and substream 200 kps. Still trying to figure out why the jump in CPU.It would be expected for one of these cams to consume 2x the CPU of a "5442" 4MP camera. Are you sure the sub stream is working? Check the Blue Iris status window. The "Sub FPS/key" column should have very similar values to the "FPS/key" column. And the Sub bitrate should also be showing a sane value.