Captured jpeg size & still pass-through

Support and queries relating to all previous versions of ZoneMinder
Locked
illtud
Posts: 2
Joined: Thu Nov 10, 2005 10:37 am
Location: Aberystwyth

Captured jpeg size & still pass-through

Post by illtud »

I'm using v1.21.3 on Fedora Core 4 using Corey DeLasaux's rpm (thanks, Corey!). I'm capturing from a pretty cheap IP cam. I can't make any sense of the stream using mplayer or similar, so I'm capturing /still.jpg (20KB) at 1 fps (plenty for me, and it will go faster). Identify (from ImageMagick) tells me that still.jpg has jpeg quality 50, which is how 640x480 fits in 20KBS.

Now my problem is that zoneminder captures alarms at quality 100, which means that captured jpegs are 138KB. I can tell it to save at quality 50 (giving me a file size of 17KB), but I'm compressing a jpeg twice, and I'm losing quality. I can go for a happy medium, but what I'd really like is to aviod recompressing at all - can't zoneminder butt out and keep the jpeg as it originally was (just with a timestamp added)?

I can go into the code and have a look, but I'd like to check that I'm not doing somethinig stupid, and whether there's support for 'pass-through' of captured jpeg stills. If there isn't, is this something that could be added? Am I totally wrong because of my ignorance of what zm is doing internally?
User avatar
zoneminder
Site Admin
Posts: 5215
Joined: Wed Jul 09, 2003 2:07 pm
Location: Bristol, UK
Contact:

Post by zoneminder »

As far as I know you can't
keep the jpeg as it originally was (just with a timestamp added)?
because the second part contradicts the first. Adding a timestamp is not keeping the jpeg as it was. What might be possible (though not currently supported) is to preserve the DCT compression information from the first image and using it on the second. The advantage of this is speed however and it becomes invalid if the images differ much.

Also, I don't exactly understand when you say
zoneminder captures alarms at quality 100
Can you expand on this a bit? Or do you mean that ZM decompresses the jpg? If so then is correct, a jpg image comes into ZM, is decompressed into a bitmap effectively so it can be examined or modified, and then recompressed for saving. You can't actually work directly on jpg images because they are just bit streams until you decompress them.

Phil
illtud
Posts: 2
Joined: Thu Nov 10, 2005 10:37 am
Location: Aberystwyth

Post by illtud »

Adding a timestamp is not keeping the jpeg as it was.
No, but it should be possible to insert the timestamp without modifying the rest of the jpeg.

eg:

% convert still.jpg -box '#000000' -font courier -pointsize 20 -fill white -annotate +0+20 "`date`" labelled_still.jpg

does just that - the rest of the jpeg is not modified, just the part where the timestamp is written to. No need to recompress. (unsure how IM does it, but the rest of the jpeg is pixel-identical and the filesize has actually reduced...)
Also, I don't exactly understand when you say
Quote:
zoneminder captures alarms at quality 100
That's my jpeg quality setting on alarm capture.
Can you expand on this a bit? Or do you mean that ZM decompresses the jpg? If so then is correct, a jpg image comes into ZM, is decompressed into a bitmap effectively so it can be examined or modified, and then recompressed for saving. You can't actually work directly on jpg images because they are just bit streams until you decompress them.
What I'd like is that is just saves the original (+ timestamp) jpeg. I don't save the alarmed composite images, and examination can happen on a decompressed bitmap, but there's no need to save that.
User avatar
servbg
Posts: 12
Joined: Wed Mar 17, 2010 9:09 pm
Location: Sf,BG
Contact:

RE:

Post by servbg »

Is it done by the new versions of ZoneMinder? I see that the post is rather old...
Locked