Diffrent resolutions
Diffrent resolutions
I start by apologizing if this already has been discussed here, i didn't take time to read through all posts.
High resolution is very important when you look at events trying to identify something/someone, but it is not nessecerely important with highres for determening if there is movement in in a picture.
So i would like to see a option to use half or maybe a quarter of the capture resolution for the detection module.
It would be possible to try something similar by using 2 monitors per camera, one that is in fullres in nodect and that is triggered by a half/res monitor capturing from ZMS but do not believe that it would get eny faster due to all tranformations so a builtin function for this that can get the image directly from sharedmemory would be great!
High resolution is very important when you look at events trying to identify something/someone, but it is not nessecerely important with highres for determening if there is movement in in a picture.
So i would like to see a option to use half or maybe a quarter of the capture resolution for the detection module.
It would be possible to try something similar by using 2 monitors per camera, one that is in fullres in nodect and that is triggered by a half/res monitor capturing from ZMS but do not believe that it would get eny faster due to all tranformations so a builtin function for this that can get the image directly from sharedmemory would be great!
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Btw, this is one of the reasons why i asked about this, look at http://www.elphel.com/, very interesting, high resolutions at high enough fps,
I do not even dare try to figure out the load of motion capturing from one of their devices will be
I do not even dare try to figure out the load of motion capturing from one of their devices will be
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
-
- Posts: 7
- Joined: Sun Sep 18, 2005 7:11 pm
-
- Posts: 7
- Joined: Sun Sep 18, 2005 7:11 pm
Re: Diffrent resolutions
We implemented something like this in the camera "hardware" (fpga), combined with JPEG compressor. There is some integral data for each macroblock (DC-component - average value, sum of high-frequency components, etc.) available to the software that can simplify such process.boaba wrote:So i would like to see a option to use half or maybe a quarter of the capture resolution for the detection module.
It would be possible to try something similar by using 2 monitors per camera, one that is in fullres in nodect and that is triggered by a half/res monitor capturing from ZMS but do not believe that it would get eny faster due to all tranformations so a builtin function for this that can get the image directly from sharedmemory would be great!
When using pure software solutions on the client side it can be possible to tap into JPEG decoder and use DC-components without performing computationally-intensive 2-d DCT, that can save the CPU load if you do not need to monitor the video when no trigger events are detected.
You should ship one to Phil.
I'll check and see if I have an address for him and PM it to you. Else you should PM him directly for the offer and to get an address would be the best route. Anouther option might be just to have a camera accessable on the internet and PM the URL for it and we can test using that route. Also any options syntax that might be available via the URL to request the image would be helpful.
Regards,
Cordel
I'll check and see if I have an address for him and PM it to you. Else you should PM him directly for the offer and to get an address would be the best route. Anouther option might be just to have a camera accessable on the internet and PM the URL for it and we can test using that route. Also any options syntax that might be available via the URL to request the image would be helpful.
Regards,
Cordel
-
- Posts: 7
- Joined: Sun Sep 18, 2005 7:11 pm
Cameras are usually available as http://camera1.elphel.com, http://camera2.elphel.com, http://camera3.elphel.com and http://camera4.elphel.com but it is much better to use them directly on the LAN - when using maximal resolution/frame rate and with high enough JPEG quality you can get as high as 70mbps - too fast for my ADSL connectioncordel wrote:You should ship one to Phil.
I'll check and see if I have an address for him and PM it to you. Else you should PM him directly for the offer and to get an address would be the best route. Anouther option might be just to have a camera accessable on the internet and PM the URL for it and we can test using that route. Also any options syntax that might be available via the URL to request the image would be helpful.
Regards,
Cordel
As for interface - actually it is now under discussion to be redesigned. Historically I used some incrementally self-made one (comments before main() in : http://cvs.sourceforge.net/viewcvs.py/e ... iew=markup) - it is now a real mess.
And Alexander Melichenko implemented (at least partially) Axis API (https://sourceforge.net/project/showfil ... _id=347493) .
As for contacting me - emails shown on elphel web site will work OK.
Andrey
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Re: Diffrent resolutions
If there is space over in fpga for either making a second lower-resoulution "stream" for alarm detection in ZM or making the motiondetect in the camera and then let the camera trigger zoneminder might work.andrey_filippov wrote:
We implemented something like this in the camera "hardware" (fpga), combined with JPEG compressor. There is some integral data for each macroblock (DC-component - average value, sum of high-frequency components, etc.) available to the software that can simplify such process.
When using pure software solutions on the client side it can be possible to tap into JPEG decoder and use DC-components without performing computationally-intensive 2-d DCT, that can save the CPU load if you do not need to monitor the video when no trigger events are detected.
i hope you and phil succeeds in making this work together!
oh by the way, this is a looongshot but if zoneminder was able to save the ogg/therora-stream from the camera direcly when there is an alarm it would save cpu too, but i have no idea if it is possible to "chop off" a stream and make a new one without recompressing, some one who use ogg/theora might be able to answer that?
and andrey: a 6 Mpixel (or something like that) camera with fisheylens = a possibility to make a all digital PTZ
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
-
- Posts: 7
- Joined: Sun Sep 18, 2005 7:11 pm
-
- Posts: 7
- Joined: Sun Sep 18, 2005 7:11 pm
Re: Diffrent resolutions
What is actually calculated in FPGA right now (approximately) is described here:boaba wrote: If there is space over in fpga for either making a second lower-resolution "stream" for alarm detection in ZM or making the motion detect in the camera and then let the camera trigger zoneminder might work.
https://sourceforge.net/forum/forum.php ... _id=364001
The difference is that in that was for earlier model 313, in the 333 FPGA is bigger and there is a second DMA channel where this data can go instead of interrupts+pio in 313.
But to be honest - I've just reimplemented that functionality, simulated it but haven't wrote any C code to program the second DMA channel on the CPU side and handle that data. So it is in FPGA but may contain bugs.
Hope that data can help to detect motion - software will have to handle much less data and it is rather easy to port a C program to camera to make the processing inside and not use network bandwidth.
As for some special FPGA code for the motion detection -it can be possible. But my only experience with motion detection so far was with self-made frame grabber for Soviet approximate clone of Apple ]{ where I had live (50fps) 128x128x4bit video and made a program to monitor a single pixel to switch graphic screens and so to make a frozen image of everybody who passed by. That was in 1984, I believe.
I believe there much more elaborate algorithms for that now and to combine strong sides of FPGA and the software it makes sense to implement some logically simple algorithm on the pixel data in FPGA but have the software process it additionally, handling less data but implementing more complex algorithms and making decisions.
We now have two branches of code - with Theora and MJPEG. Now I'm adding more functionality to MJPEG waiting till the software for the rendering of the video - originally I found that computers are too slow. Even the dual-xeon 3.6 that I bought for that was not fast enough (but close). What I would like to develop for Theora is a PC-based server that record full resolution video in Theora format and transcode it to lower resolution MJPEG (without DCT - just in coefficient space) by decimating 2/4/8 times (so you can use the same DCT coefficients) and/or windowing. And streaming the video with format possibly emulating popular cameras.boaba wrote: oh by the way, this is a looongshot but if zoneminder was able to save the ogg/therora-stream from the camera directly when there is an alarm it would save cpu too, but i have no idea if it is possible to "chop off" a stream and make a new one without recompressing, some one who use ogg/theora might be able to answer that?
So operator can view multiple cameras in parallel (remember - full resolution/full frame rate Theora needs all what a PC can do for just 1 camera), use digital PTZ real time, but the full resolution video still going to the hard drive on the server. So that ditital PTZ will be complemented by the time machine - if something instantaneous happened - you always can go back in time and zoom on details that operator did not care earlier. With low resolution and real PTZ CCTV camera in Moscow, Russia was just looking the other side when explosion happened.
Micron will have 5MPix camera next year (short info is on their web site). It has twice higher pixel clock but will match the challenge.boaba wrote: and andrey: a 6 Mpixel (or something like that) camera with fisheylens = a possibility to make a all digital PTZ
As for digital PTZ - I hate it, it's a real waste. IMHO all the sensor data should be processed efficiently compressed and stored - PTZ just for operator - both in real time and to watch records on the monitor that has lower resolution than the camera.
Andrey