MaxIcon

Yeah, this may be what's happening, though we've seen the Hik sensor isn't great at low light, but that could account for the lower price. Thinking on it more, many still cams now have 1080p/720p video capability, so that would be built in to the chip. The only fly in the ointment is the relatively low resolution - 2.5MP is very low for a still cam these days, but they may tether sensor elements together for video output to get better low light performance. Sounds like some research is in order. I realized I made an error in one of my assumptions - it doesn't affect the results, but the sensor size (in mm/inches) calculation is wrong. Sensor sizes are misleading, due to the history of sensors as originally embedded in glass tubes, where the size was the tube internal diameter, not the sensor internal diameter. So, a 1/3" sensor is actually smaller than 1/3" on the diagonal, generally by about 1/3, but there are no specific rules for this. This is discussed in a lot of places, and here's one: http://www.dpreview.com/news/2002/10/7/sensorsizes This would mean my physical size calculation is off by roughly 1/3, but the resolution and aspect ratio calcs are the same. I knew about this, and have posted it before, but didn't consider it in this case.

It is a little disappointing (and may be why Swann only markets these as 1080p), but what's puzzling is the odd sensor size. This isn't a set of specs usually used for ip cams, unless this is a common size used for some other apps. The 3:2 aspect ratio is what traditional 35mm film uses, but these sensors don't usually have the properties of a video sensor, and tend to be expensive.

Are they both set for the same maximum exposure time? The bullet shows noise at 1/30 sec if the light's low, and gets much better as you increase to 1/12 or 1/6.

Here's a tighter close-up on the hard drive in the Swann, which appears to use the same components at the Lorex except for the MB: viewtopic.php?p=217647#p217647 It's definitely a eurs here.

OK, here's my analysis on the Hik/Swann 3MP sensor resolution. Thanks to Mark at cam-it.org for posting a great high-res pic of the sensor that really helped with this, and for Q's and Buellwinkles pics of the 1080p and 3MP images. tl;dr version: The Hik sensor appears to be about 2.5MP, with sensor resolution of 1275x1920, for an aspect ratio of 3:2. Assuming the 1080p image is true 1080p, the 3MP image is actually a 2.2MP image, scaled up 120% to give an apparent 3.2MP image (note that MP scales with the square of the horizontal and vertical resolution). I could be wrong, but all the data works together pretty well, if you want to slog through the rest of the post. If anyone sees any flaws in the reasoning, I'm always open to corrections. First, a couple of assumptions, because you have to start somewhere: - The Hik and the Swann are mechanically and electronically identical, with just minor firmware/NVRAM differences. Based on Buellwinkle's images from a Hik, this is a pretty sure thing. - The Hik is a true 1080p camera - that is, when it puts out 1920x1080 pixels, they came from 1920x1080 sensor elements. We'll assume Swann's marketing and specs are true and correct, and that Hik's 3MP specs are in question. - The sensor size is 1/2.5". One complication in all this is the Hik sensor size spec. The web page says it's 1/2.5" (0.4") diagonal, while virtually all the online docs (PDFs, flyers, etc) say 1/3" (0.33") diagonal. The data shows it's likely to be 1/2.5", and it looks like they updated the web page but not all the rest of the data. ETA: This was a mis-assumption, as I forgot that sensor size listed isn't actually the real sensor size, but is about 50% larger than actual sensor size, due to the history of sensor construction. This doesn't affect the resolution and aspect ratio results, but means the physical size is different than calculated. Here are the image specs from Hik: 1080p = 1920x1080 (2.1 MP - this is 1080p by definition) 3MP = 2048x1536 (3.2 MP - there are no 3MP standards, so this is what they chose) Most of the sample images below are reduced to 1/3 their original size. For starters, here are Q's original images that started me wondering about this. Since the 3MP image specs show more pixels in both axes, the 3MP should have more horizontal image showing, but it actually has less. This says that the 3MP 2048 horizontal resolution is really less than the 1080p's 1920 pixels. The 3MP vertical 1536 resolution is larger than the 1080 resolution, so it is seeing more than 1080 pixels vertically. Not only that, switching between both images shows the 3MP is zoomed larger than the 1080p, and if it was capturing actual sensor elements, everything common between the two images should be the exact same size, with more image around the edges of the 3MP image. Here are these images, reduced by 1/3. The key is to see where each image stops compared to the other, as that's where the captured sensor pixels stop. 1080p image: 3MP image: How to figure out what the real resolution is? Again, assuming the 1080p is correct, the easy way is to scale down the 3MP and overlay it on the 1080p until they match. This happens at about 83%, as seen below. If you scale down the horizontal and vertical pixel counts by 83%, you get this, which is what I posted in the original thread: 3MP actual = 1700x1275 (2.2 MP) Here's the 83% reduced 3MP image overlaid on the 100% 1080p image. We assume that the sensor maximum horizontal resolution is 1920, since that's the 1080p horizontal resolution, and we then assume the sensor maximum vertical resolution is the 1275 that the 3MP uses, because if they had more, they'd use it, you'd expect. This gives us a sensor resolution of: Hik sensor = 1920x1275 (2.5 MP) - note that this isn't 4:3 (SD) or 16:9 (HD), but is about 3:2. Now, it's very difficult to tell what's going on in the software, so the next step is to look at the actual sensor and see if it fits. Cam-it member Mark posted a huge pic of the sensor mounted to the board - here's a reduced version. This is a very useful picture, as we can tell several things from it: - The aspect ratio of the imaging section of the sensor chip - The relative size of the chip compared to the SMD resistors, which come in standard sizes First step is to determine how many pixels wide and tall it is. This is easy in an image editor; by selecting the imaging area, you just look at the pixel size of the selection. It turns out that the aspect ratio is about 1.5:1, or 3:2 - the same size as the estimate from the image scaling above. This is good, because it helps verify the initial estimate! Next, the resistors are measured. It's hard to measure them accurately end to end, because of the solder, but most smaller SMD resistors are twice as long as they are wide, and the width is easy to measure. This gives us the length of a resistor in image pixels. Since we know how many image pixels the sensor is, we can then calculate how many resistors tall and wide it is, and it happens to be about 5.1 resistors tall and 3.4 resistors wide. SMD resistors come in various standard mm lengths, like 0.6mm, 1.0mm, 1.6mm, etc. If we convert the number of resistors to mm length, then convert that to inches, that gives us several possible sizes for the sensor's horizontal and vertical dimensions. Since we know the diagonal is either 0.33" or 0.4" (and suspect 0.4" is correct), we can calculate the diagonal from X^2 + Y^2 = Z^2. Plugging in the various resistor standard lengths, a 1.6mm resistor gives us a sensor size of 0.39", which is plenty close enough to 0.4, given the sketchy measurements. ETA: Due to the physical image size being roughly 2/3 the listed image size (see a few posts below), this isn't right. It's more likely these are 1mm resistors, and it just happened the 1.6mm size fit in the sensor size scaling. The other conclusions are still valid. So, using a completely independent set of measurements, this supports the original 3MP scaled estimates done by overlaying the images. At this point, my confidence in the results is pretty good.

I think he meant most IP cameras have a 100Mb connection, not actual bandwidth.

I'm working up an analysis of the sensor, and am just about done. I'll post the results, but assuming the 1080p image is true 1080p, the 3MP definitely not true 3MP. This is the case for both the Swann and the Hik, which appear to be the same camera in every detail except minor data in the non-volatile RAM. There's no obvious downside to flashing the Hik firmware, as far as I can tell, and the bugs I thought I saw aren't really there - see a later post in this thread. I never trust X.Y.0 firmware. The upside is that you get the extra 4:3 mode, which is slightly higher resolution than the 1080p, but the real question is which aspect ratio works better for you. There are a few other minor improvements, but nothing major. The 2 images I use for most testing are the Siemens star and the ISO-12233 chart. If you want to use either one very far from the camera, a bigger print works well, especially with the ISO chart. The Siemens star is great for focusing and comparisons, while the ISO chart is good for actual measurements, since you can determine a number where the resolution goes blurry. The problem is that most cameras need it to be really close, which may not be the focus area you need. One useful trick with the ISO chart is to pick one of the numbered resolution sections and just print that on a piece of paper, then tape it to cardboard. This way, you can get actual measurements - at 10', camera A has 550 lines resolution, while camera B has 600, for example. The latest Acrobat viewer will print poster-style, where you can print on multiple pages and mount them on a larger sheet, or you can do this manually, but it's easier to get a big print at the print shop. Here's a huge, clean, scalable Siemens star in .png format: http://upload.wikimedia.org/wikipedia/commons/thumb/5/50/Siemens_star.svg/2000px-Siemens_star.svg.png and an excellent free ISO12233 chart in PDF: http://www.graphics.cornell.edu/~westin/misc/ISO_12233-reschart.pdf

You'll need an alarm input on something. The easy way is with an alarm input on a camera - some cameras have them included, but the HFW2100 doesn't. The 2 and 3 MP Dahua bullets do have them, as do many other cameras. One option would be to include one camera with an alarm input in a key location and trigger the others off that, assuming Vitamin D supports that. Some software packages support add-in cards with alarm inputs (Aver, for instance), but you need an expansion slot for that, and I don't believe the Mini has one. I don't know if there are any USB based alarm inputs at all, or ones that Vitamin D would work with if they exist.

Unless you really need that many cameras for that price, I'd avoid analog cameras. IP cams are the new order, and analog, while the corpse is still shambling around, is clearly in zombie mode. Might get some heated responses to this, but I unplugged all my analog cams a while ago. Better sell them while they're still worth more than landfill, I guess.

Higher bit rate is mostly going to affect scenes with a lot of change or fast motion (higher bit rate gives less pixelization), and for detailed images it can help by allowing less compression on both the i-frame and the p-frames. Distance resolution will mostly be helped by making sure your focus is optimized for further away, rather than nearer, or by putting a longer lens in. Sometimes you can improve it by going with a better quality lens, but this can be a hard thing to get solid info on with M12 board cam lenses. I always run at higher bit rates, rather than lower, unless there's a compelling reason (like the BI limitations Buellwinkle mentions on the 2 and 3MP Dahuas, which are improved on the newer versions). I run all my MP cams at 8192 if I can.

If you have a lot more time than money, it's always a learning experience to work with little known brands with limited technical support, and learning is good. If you want to get a camera up and running with the option of using a variety of software solutions, it's often worth spending more for a brand that's well known and commonly used, as community support can be very useful when the manufacturer can't help.

I did see that and used the trial version. The motion detection has more control then the nvr software i am using now but still is based on pixel change. i would really like something that can detect objects and such. BI has a version of object detect - it comes selected by default on the motion detect screen. How well it will work for your situation would have to be tested, but I found that it started recording when something moved across the field of view, but when I picked up the camera and moved it around, it wouldn't detect that as motion.

So, it appears that both act the same, as Buellwinkle found, which indicates that the Hik 3MP mode is actually a scaled (interpolated) output from the sensor. The pics of the sensor make it appear to be a 16:9 sensor, while a typical 3MP sensor is a 4:3 sensor, and the 1080P uses the full width with fewer vertical pixels. This is how the Dahua 3MP appears to work. Unfortunately, it's very hard to say for sure what's going on internally, but it's pretty clear from Buellwinkle's image that it's not a true 3MP, since the 3MP spec has more horizontal pixels than the 1080P, while this image has fewer. An estimate of the Swann's image showed it to be about 2.3MP equivalent in the 3MP image, assuming the 1080p image is true 1080p. It looks like the Hik 3MP cam has the exact same image proportions, but I haven't checked them closely.

Usually you'll find auto-focus on PTZ or remote zoom cameras, as they need it when the zoom changes. Some higher end cameras support it as well - I haven't used it, but others talk about how much easier it is to auto-focus from the PC instead of climbing up a ladder with a tablet or laptop. If you search on auto focus, you'll find a bunch of topics, including some camera models.

Another potential issue with a Mini running Windows and Blue Iris is that the Mini tends to use relatively low power CPUs, which is good for power consumption and noise but bad for handling multiple 2-3MP cams. If you're considering that path, you should check some of the performance threads over at cam-it.org, and see how the Mini's CPU benchmarks compare to what others are running. It does have a 15 day free trial for testing, but the demo version doesn't enable direct to disk recording, which reduces CPU load a fair bit.

I've had good luck with my 1MP Vivoteks, as well. They've been some of my most reliable and fiddle-free cameras, except the IR filter can get unreliable after a few years. I have one I keep in night mode 24x7 because of this. Don't know how the newer models compare, though.

This. You really have to play with it to figure out what works best for you. I set each slider to the ends and the middle to get a feel for the overall effect, then start fine-tuning. Too much sharpness can be a problem when the video's noisy, as it really highlights the noise with sharpening artifacts (little rectangular bars and shapes), and makes it look a lot like motion at night. I never saw much effect from noise reduction, but didn't mess with it much. The other major trade-off is maximum exposure time vs noise. Longer exposures give much better night shots with lower noise, but cause motion blur and reduced frame rates. I never go below 1/30 second, as a low noise image that's completely blurred is not much good, but the Swann does tend to get pretty noisy at this setting if there's not much lighting.

And to expand this a little more - does the Hikvision software work with Lorex, as well as Swann? That is, can you download the Hik version and use it for either of these? Likewise, does the Swann software work with Lorex, and vice-versa? If they're all Hik systems, I'd hope they would. I think we've seen that the software from the Hik website works with the Swann cameras; how about the rest, like PSS?

Thanks, all, this is something I've been interested in, and it was a good opportunity to run the tests. This is all in Silicon Valley, where we freeze when it gets below 60, and bake if it's above 80. BLC (back light correction) uses a specific area of the image for setting the exposure speed and iris (if the camera has auto-iris). Usually, it's used for things like watching a store's door, where it's brightly lit outside and the entire store front is glass. With normal exposure, it adjusts so that the whole image is exposed correctly, so someone walking in the door will be dark due to the light from outside. Setting BLC around just the door will adjust exposure for that area, which will make a person standing in the door exposed correctly, but everything else will be washed out. That's the main difference between BLC and WDR - BLC only cares about the part you tell it to watch, while WDR looks at the illumination of the entire image and adjusts for better exposure balance across the whole thing. WDR is much better when it's well programmed, but it's a good bit harder to do right than BLC. BLC is enabled in the camera. This is one place where the Dahua is superior to the Hik - the Dahua lets you draw a box around the area you want to use, while the Hik just says up, down, left, right, center, and doesn't show you what area it's using. There are no other settings, like the 0-100 slider on the Hik or the Weak-Medium-Strong on the Dahua for WDR. For the Hik, I just tried different settings until I got the best one, and that was down, not center as I expected. The IR from the Dahua may have contributed to the problems, as seen in the clip you got the license frame from. I have some other tests with the Dahua in a static environment that I'll post up when I get a chance, as they give a pretty good example of the differences in the modes. In those, BLC worked best overall in difficult lighting, as long as you could keep the lighting in the BLC area.

No, seems unlikely that would shift suddenly. That makes it seem more like foam changing, since cleaning the dome didn't help. I had one camera that developed a film on the lens from something, and cleaning the lens helped, but that doesn't seem too likely here either.

Before messing with the foam, you might want to make sure it's not environmental reflections back to the dome. Best bet for this is to put it out in the open, pointing straight up into a dark sky. If the IR reflections are still there, it's coming from the inside of the dome. If they're gone, it's coming from something around the camera, reflecting back onto the dome from outside. This takes relocating the camera or painting the area that's reflecting.

You can often find out who the OEM is by googling the software revision from the web page report. Sometimes you need to put it in quotes. Aside from the manufacturer's apps, IP Camera Viewer Pro is a great app for both Android and iOS.

As an aside, there's an industry in private LPR databases developing. Essentially, people drive around and capture license data along with GPS and street data, Google Street View style, and put it into private databases of license numbers and locations. Access is sold to those who want or need it - repo firms, private investigators, stalkers, whoever. The government won't supply this info to private citizens, but the current laws allow for independent collection of such data for private use. Fascinating example of technology's unintended consequences! So, for a dedicated LPR system, Buellwinkle's recommendations are good if you have the cash and can mount the cameras and illuminators appropriately. IR gives the benefit of predictable illumination, and coupling that with a small field of view, you can set the camera for good exposures, as he mentions. For those wanting to use their home cameras, it's a set of trade-offs, as always. Using IR causes exposure problems, while not using it gives better images, but if someone turns off their lights before getting into range, the lack of illumination prevents good images. This is especially problematic with fixed lens cameras like the Swann/Hik, where the lens can't be changed easily. Dedicated cams with long or varifocal lenses will solve part of this, but can cause problems with the Wife Approval Factor, if they don't like bigger cams hanging on the front of the house. This is why there's a market for dedicated LPR systems, which can be fairly expensive by home security standards, but are reasonable for corporate/commercial apps.

I haven't tried either Dahua or Hik domes, but assuming they're the same basic sensor, processing, and firmware as the bullets, the Hik image quality is better overall. The Dahua 3MP bullet has problems with soft images in the shadows and weird color shifts (there have been several threads on this), though both of these problems may be fixed by software updates. Dahua's lack of support is legendary. Your supplier may be able to provide firmware and technical support, but you can't get it direct from the manufacturer, and you can with Hik. I've never yet seen a list of software update features from Dahua, though some claim the sellers have it, but nobody's ever posted them. Hik posts them on their support site, along with the firmware.

So, I'm a big fan of BI, for all the reasons listed above. Also, there's no per-cam license fee, annual maintenance costs, or license renewals, which is awesome for those of us who switch cams around a lot and use a number of them on a budget. Is it a security system for high-end industrial/corporate users? No. It doesn't do a lot of the corporate/business stuff like POS monitoring, map-based layouts, multi-cam playback, sensor integration, whatever, but what it does, it does very well. It doesn't have built-in remote client access like the big boys have, either. You can't expect everything for $50. I have an Aver system with many of those features (but still no per-cam fees), few of which I use. It's for backup, and 95% of my day to day usage is on BI. For those using a system for home security, small business monitoring, hobby use, etc, it's the best deal out there. You can't beat it for anywhere near the price. Understood that it's not for everyone, but most of those it won't work for have a bigger budget than those of us who swear by it. And yes, you can set up a watchdog, using Windows scripting. The BI community forum has worked up a powerful and flexible one that got me through some network port drop-out problems on one of my boxes. Did I mention the community support forum? No, it's not for the high power corporate types either, but if BI fits your needs, you should check it out.