ZoneMinder Forums

First off, I realize that the camera would have to change it's jpeg images or mjpeg stream for this to work... and Zoneminder would have to initiate this change in order for it to switch to the higher res picture...

But wouldn't it be nice? Duiring non-alarm state, a lower quality (320x240 perhaps) image is recorded... when the alarm is tripped, suddenly images are captured at a higher resolution (say 640x480).

Just thinking about this, it obviously creates a lot of problems. The change in resolution iteslf would probably trigger an alarm state (as a lot would have changed from the previous image)...

Just a crazy idea I though I would pass along.

--Pathway

I can see why this might be desirable, However this is not trivial

Certainly you would not want to be interrupting and reconfiguring your cam or ip feed to a larger resolution just when something interesting is happening so you would probably have to capture at the higher resolution the whole time but perhaps just store the files at a lower resolution for when nothing is happening. I'm not sure how much this would save over perhaps just intentionally degrading the image quality by increasing the jpeg compression of the larger image, which is something that would be more feasible and come without the attendant issues of resizing in mid replay stream etc.

Furthermore, if an alarm occurs and you want to include x seconds of preamble then all those frames would be at a lower quality. This could obscure valuable detail of activity that may not have been high enough to trigger the alarm earlier but still important enough to want to retain.

Mathew

That again would be trivial, the images buffered in shared memory would still be in a high resolution state so what ever you have your prealarm buffer set to to determine how much time you have before the event. The degradation would not happen till the event is stored to disk. Of coarse I know that Phil wold make this a configurable option so if you don't want it, you don't have to use it. Most of the process is already in ZM as a configurable option on stream and storage quality in options so this would just enhance the existing feature so to speak.

I'm not sure I follow but I'm sure you've got it sussed!

cordel wrote:That again would be trivial, the images buffered in shared memory would still be in a high resolution state so what ever you have your prealarm buffer set to to determine how much time you have before the event. The degradation would not happen till the event is stored to disk. Of coarse I know that Phil wold make this a configurable option so if you don't want it, you don't have to use it. Most of the process is already in ZM as a configurable option on stream and storage quality in options so this would just enhance the existing feature so to speak.

Hey! What a great idea!

My original idea was to capture at the lower resolution and move up when the alarm is tripped... but you're right... if you capture at the higher res and only save a lower resolution version (hoping that the image resize doesn't take too much cpu power)... this would be a great way to save disk space.

My way was much more complicated... I like this idea better. Sm:)e.

Actually, this could be done as an "after the fact" thing... If a deamon deturmined that the machine wasn't wasn't too busy, it could go over non-alarm images and reduce them as it has time. If the load goes up (or if you just re-nice it...) then this deamon could be placed on hold while the system needs the cpu power. (But, this again adds more complications.)

Just more crazy ideas.

--Pathway