-
Notifications
You must be signed in to change notification settings - Fork 0
Configuration parameters
Explanation of main parameters which user can modify/adjust for different purposes. These collection of parameters stored in configuration file
Represents definitions of changed color. Every pixel information stored in 24 bits: Red, Green, Blue channels respectively. 1 byte per channel, that means maximum change per channel can be in range 0-255, and maximum total difference for the whole pixel can be 765, so, possible range 0-765. After a few tests with real images made in daylight, the optimal value for this parameter is around 200. But it will change depending on light conditions, especially in night light, or for specified modes in a camera that provides images.
Shows numbers of pixels for every particular object, in other words, it`s a definition of how many pixels connected will mean that its potential object. This parameter depends on the resolution. If the camera will change resolution in runtime this parameter should be adjusted respectively. Because on a bigger resolution the same object will take more pixels as well.
This parameter will define how frequently pixel check will be done. For optimization purposes no need to check all pixels - it will load CPU too much. Requirement: this value of pixel step should be able to detect at list one pixel in the smallest possible object.
In case of the calculation has to be done in time for using results in other components, programs, services - nice to have maximum duration limit of calculation, to not block of detection system at all. If calculation can not be provided in time, the user should be notified about this problem, and calculation can be started on the next image. At the same time, the user should react on this and adjust input parameters, or check camera stability and related environment.
In case of vibrations results will be distorted, and analyzing such images will take much longer because existing objects will be marked as changes, but actually it will be the same objects from the base image just sliding in different directions. No needs to check such noise because an external tool can require results in time. If the calculation limit will be exceeded, the calculation will be terminated related messages will be shown to the user, and the program will be able to do the next comparison.
In up-to-date systems all CPU supports multi-threading and it makes it possible to do calculation fast. In tests with 3-5 objects on full HD(1980x1080) and QHD(2560x1440) resolutions program in release version able to provide results with all stack of calls(reading images files, data extraction, search objects) will take around 100ms(8 threads CPU). That means the library able to provide results a few times per second.
The value should be set in seconds, in case if it is less than 1 second, for example, 500ms value will 0.5.
In case if changes not found in current attempt user can define idle time, to avoid not needed calculation all time. During this time the current library will not do any calculation and CPU will be not loaded, just waiting defined idle time, and then check will be started. It will reduce power consumption and a superfluous load of resources. Value should be set in seconds.
Floating number which represents a multiplier of threads per each CPU core. Can improve image processing speed depending on CPU specification. Warning: On the other hand, the wrong value(too big or too small) can make calculation slower than with default value. In case if the value set to 1.0 that will means to use 1 thread per core, where core count defined for every type of CPU. Depending on the complexity of processed images, the value of this multiplier can be adjusted, but it is not easy to predict optimal value for all possible circumstances. Frequent processing with 100% CPU load can produce increase CPU temperature and possibly overheat, which usually make a negative impact.