API Snapshot quality is MUCH worse than Web Snapshots - blocky artifacts in shadows plus overall lightening

[alekk]

TL;DR - Why are the jpeg's obtained via the API Snapshot MUCH worse quality than the png's from using the web interface?

2024_01_09 Update: Per @duplo post #18, you can change some "SnapFormat" settings which will improve the quality. I still feel that if you compare the JPEGs as generated from the Camera API versus similar-sized JPEG's generated from Photoshop from the PNG, the camera could do better. Makes me wonder about the internal algorithms ... but may be related to dynamic range comment below.

Also, per post #21-24 where I show Histograms, the "lightening" appears to be from compression of the dynamic range by boosting the shadows and knocking down the highlights. I'll point out that Hikvision has a Grey Scale option (Image->Image Enhancement) where you can choose the range of the grey scale as [0-255] or [16-235] ... the later is what seems to be happening.




I use a perl program to snarf the API snapshot ... but you can also get that by simply surfing to USERNAMEcolonPASSWORDampersandIP/cgi-bin/snapshot.cgi

I've been using IP cameras for a few decades - mostly recently Hikvision. But I've seen some nice products from Dahua, and this forum is much more active ... plus @EMPIRETECANDY is super responsive. So I decided to take one of the latest cameras for a spin - specifically the "latest 5442-ZE-S3 AKA T54IR-ZE-S3" as discussed in this thread.

I ordered it from Andy's Amazon store on 12/10 and it showed up the next day - can't get much better than that!

While there are a few differences from Hikvision, the setup was fairly straightforward ... as imaging is ... wellllll ... imaging! ;-)

I'm impressed with the camera so far ... with low light quality (the main thing I'm looking for) a definite improvement over the Hikvision (similar lens specs, but several year old sensor) I'm currently using.

But one thing that is REALLY bugging me is the quality of the jpeg Snapshot images when you snarf 'em via the API (/cgi-bin/snapshot.cgi) are MUCH worse than the png's obtained from the web interface.

I have tried all sort of encode combinations (compression, VBR/CBR, Bit Rate) and I see the same significant difference in image quality. Camera settings are close to default, with shutter speed set to 100msec (yes, I know that 1/10s is slow - I see it at faster shutter speeds), gain cranked up to 75 (I see it at lower gains), Noise reduction is at 50/50.

Yes, the Web PNG is 5,340KB versus the API JPEG is 256KB ... and yes, I appreciate that the API call returns a compressed image ... I have not found a way to change/specify the quality. If open the Web PNG in Photoshop, save it as a JPEG at quality 10, the resulting file size is about the same ... but doesn't have near as much blockiness. Even if I save as JPEG quality ONE(!), it doesn't look that bad. Another things I notice is the image is lightened (which probably contributes to the blockiness) resulted in a washed out look. I'm wondering if there is some sort of funky auto-leveling, gamma correction, and/or shadow pushing in generating the JPEG?

The camera is clearly capable of generating a (pretty darn good) PNG ... so why is the JPEG downloaded from the API so poor?

I'm wondering if others are seeing that on this camera or other Dahua's? And if so, is there any workaround to get a "decent" image via an API call.

Images attached in the next thread comments. Again, I LIKE the camera ... just wondering WTF is going on here and hoping to find a solution. TIA for any suggestions.


P.S. While this image is replicated below, I'm posting it here so you can quickly see what I'm talking about - note the the lightening plus the blockiness.

 

[alekk]

Here are the original images from using the web interface versus the API call.
The PNG is 5,340KB versus the JPEG is 256KB.
Take a look at the street - that's a crapload of black/grey blockiness!

 

[alekk]

Here's the web interface PNG (5,340KB) resized in Photoshop to Quality 10 (254KB) and Quality ONE (194KB).
Both are better quality than the image above that the API call returns.

 

[alekk]

Here's a GIF (glad to see the forum allows it to cycle) that shows the Web snapshot versus the API snapshot.
So yea, when I convert to GIF, the color space changes ... but if you look at the originals I posted above, you'll see the same "lightening" of the image. That's why I'm wondering if there is some sort of funky auto-leveling, gamma correction, and/or shadow pushing in generating the JPEG which is causing some terrible blockiness in the shadows.

 

[alekk]

Finally, here's a comparison of the "road area" of the Web versus API snapshot. This done by pulling the originals into Photoshop, cropping the same 1500x400 top right corner, and then combining into a single image. You can "see" the lightening plus the blockiness.

 

[alekk]

While not as obvious in the daytime pictures, the same problem exists.

1st image is the 3,697KByte PNG as generated from the web interface.
2nd image is the 187KByte JPEG as generated from an API snapshot.
3rd image is a 170KByte JPEG generated from Photoshop using the the original PNG and saving as quality 5(!) ... which even that is better than #2.
4th image is images #1 and #2 overlaid as a GIF to more easily see the blockiness and lighting of the image, especially in the shadows.

 

[alekk]

Reserved for update/solution ... I hope! ;-)

 

[alekk]

On post #190 of this thread, @bigredfish posted some images showing the exact same problems with the "big brother" Z4.

As mentioned, maybe it's because I'm a photographer, but the banding just jumps out at me as absolutely terrible from the API image. Yes, you would obviously expect some drop in image quality, but seems like waayyy more than one would expect. I opened his 12 MByte PNG in Photoshop and saved it as a JPEG with the SAME SIZE as the JPEG obtained from the API Call. I then cropped the lower left hand corner to compare those three images.

This demonstrates exactly what I'm seeing - is there any doubt that the API image looks MUCH worse ... even though the "saved JPEG" is the same size?

 

[wittaj]

Maybe the API is capturing it in-between iframes?

 

[alekk]

Maybe the API is capturing it in-between iframes?

Good idea @wittaj , but I should have been more clear above that I have looked at this a LOT ;-)

The camera is running at 6FPS and I've trying varying the Compression, Encoding Strategy, CBR/VBR, etc.
It's super simple to grab a PNG from the web interface ... and then I just compare to the same time (to the second) image that my program pulls every second. In ALL cases, I see the same dramatic image degradation in the snapshot.cgi JPEG.

I.e. you would think that if this was an "intermediate" frame problem, I would get "lucky" at least occasionally and hit a Key Frame. Super Obvious in a time-lapse video ... the noise/banding "moves" around, but stays "bad" compared to what the camera can deliver via the PNG ... and noticeably worse than one would expect from typical JPEG compression.

 

[d5775927]

Maybe try this config:

I don't have the same model you have, but try changing the settings on that page.

 

[alekk]

I appreciate the brainstorming @d5775927 ... but I already tried the same looking tab ... except instead of being under Video (or Encode), it's under Picture->Snapshot. Unfortunately, it didn't seem to make any difference when you are doing an external "pull" via the API.

Per the Web5.0 Operations Manual, this appears to be related to if you are doing doing Scheduled and/or Event snapshots as initiated by the camera. So this would effect image quality (and frequency) if you instead had the camera "push" images by using this and sending via FTP/HTTP/etc. Which for a variety of reasons I'd prefer not to do.

 

[Webfont]

maybe with ffmpeg? How to grab a single image from RTSP stream using FFMPEG
This would use the same mechanic as the web screenshot since when clicking the screenshot button it's the web live view plugin doing the screenshotting and not the snapshot.cgi call

Edit: Wait, you said in another thread you're able to do the screenshots without any plugin on those new s3 cams? Check with F12 what the webgui is calling when you do the web screenshot, is it passing extra parameters to snapshot.cgi or calling something else?

 

[alekk]

Good idea @Webfont - here's the command line I ended up doing to generate 10 images:
ffmpeg -y -rtsp_transport tcp -i 'rtsp:/USERNAMEcolonPASSWORD@IP/' -qscale:v 1 -r 1 -frames:v 10 -s 1920x1080 image-%03d.jpg
The JPEG's coming from that are what I would expect (even if I relax qscale) and are MUCH better than from snapshot.cgi ... which echo's what I said earlier that the camera has good image quality.

So while I COULD do this, it's frustrating because I've been using this approach of directly pulling an image from the camera (with processing done there rather than on my system) for almost two decades with several different vendors. None of those (except Dahua) have such a significant difference in image quality. So I do think there is a bug somewhere in their software that they should look into.

P.S. I also appreciate your good idea to check with F12 on the browser to see exactly what command is being sent to the camera. I've used Developer Tools occasionaly ... but sorry to say I could not figure out (tried both Edge & Firefox) what exactly that button was doing and what call it was making. Regardless, this saves a multi-megabyte PNG ... what I want is the compressed JPEG ... which (having using Photoshop on the PNG), can be a tenth the size and SHOULD (!) be almost the same quality for my scene.

 

[Webfont]

Good idea @Webfont - here's the command line I ended up doing to generate 10 images:
ffmpeg -y -rtsp_transport tcp -i 'rtsp:/USERNAMEcolonPASSWORD@IP/' -qscale:v 1 -r 1 -frames:v 10 -s 1920x1080 image-%03d.jpg
The JPEG's coming from that are what I would expect (even if I relax qscale) and are MUCH better than from snapshot.cgi ... which echo's what I said earlier that the camera has good image quality.

Good! At least you have a workaround.

So while I COULD do this, it's frustrating because I've been using this approach of directly pulling an image from the camera (with processing done there rather than on my system) for almost two decades with several different vendors. None of those (except Dahua) have such a significant difference in image quality. So I do think there is a bug somewhere in their software that they should look into.

I'm not sure what's the deal with snapshot.cgi. Is the lower quality intentional? did they decide that whomever was calling this must just want disposable images so they limited the quality intentionally to save disk space? bug? No idea.

P.S. I also appreciate your good idea to check with F12 on the browser to see exactly what command is being sent to the camera. I've used Developer Tools occasionaly ... but sorry to say I could not figure out (tried both Edge & Firefox) what exactly that button was doing and what call it was making. Regardless, this saves a multi-megabyte PNG ... what I want is the compressed JPEG ... which (having using Photoshop on the PNG), can be a tenth the size and SHOULD (!) be almost the same quality for my scene.

I don't have a new s3 cam to test it, but in the dev tools if you open the network tab after opening the cam live view, click the clear to remove all entries, click the snapshot button in the webgui, and if it's just doing a normal http request you'll have a new entry in there with either a POST or GET request that you could then analyze to see what it's doing. If there's nothing new in there when you click snapshot, then the snapshot is done browser-side with that plugin-less live viewer from the image at that time, so you're out of luck.

 

[alekk]

Wellll ... the workaround of using ffmpeg will require a bit of coding to setup versus simply retrieving the latest image. Plus there's a difference between running a test on the command line versus something in production 7x24x365 that deals with the occasional camera/network oddities. Note that ffmpeg takes several seconds to "spool up/sync" ... so if you are trying to pull an image a second, you'd have to run it continuously.

In terms of image quality, see the image examples above. In my experience, ALL vendors provided the ability to get a "snapshot" image (often with a specified qualify and even size) so you can get something of reasonable size. So the fact that the JPEG is a tenth the size of the PNG is not surprising and what I see from other camera's. And yes, those images (especially at low quality) are a little worse than the "original". What's surprising about the Dahua is the JPEG is "similar sized" (compared to other camera's), but the degradation of quality is MUCH, MUCH worse. You can also see this in Photoshop by saving the PNG as a same-size JPEG which does NOT demonstrate the blocky artifacts plus overall lightening.

Thanks for the tip on Developer Tools - I had tried that earlier in Firefox and never saw anything. I just tried again in Edge and same result - I don't see a GET/POST.

 

[wittaj]

Thanks for the tip on Developer Tools - I had tried that earlier in Firefox and never saw anything. I just tried again in Edge and same result - I don't see a GET/POST.

As we often say here, try Internet Explorer. Yeah we know LOL. But many things with these cameras work better with Explorer - not Edge or Chrome with extension, but plain ole Explorer.

Would be curious if this is another example of something with Explorer.

 

[duplo]

who is even writing so much and not just look into API doc ?

if make a screenshot from webinterface, it will just be a snap of the stream which you are seeing (with your own encoding settings)

snapshot.cgi have different encoding settings..


if you open snapshot.cgi (without anything else) it will use the encode settings of "snapformat(0)"

ip/cgi-bin/configManager.cgi?action=getConfig&name=Encode

these settings need to be changed:

table.Encode[0].SnapFormat[0].Video.resolution=2688x1520
table.Encode[0].SnapFormat[0].Video.BitRate=5120
table.Encode[0].SnapFormat[0].Video.BitRateControl=VBR
table.Encode[0].SnapFormat[0].Video.Compression=MJPG
table.Encode[0].SnapFormat[0].Video.CustomResolutionName=2688x1520
table.Encode[0].SnapFormat[0].Video.FPS=1
table.Encode[0].SnapFormat[0].Video.GOP=60
table.Encode[0].SnapFormat[0].Video.Height=1520
table.Encode[0].SnapFormat[0].Video.Pack=DHAV
table.Encode[0].SnapFormat[0].Video.Priority=0
table.Encode[0].SnapFormat[0].Video.Profile=Main
table.Encode[0].SnapFormat[0].Video.Quality=5
table.Encode[0].SnapFormat[0].Video.QualityRange=6


...

try these:
Encode[0].SnapFormat[0].Video.BitRate=10240
Encode[0].SnapFormat[0].Video.GOP=1
Encode[0].SnapFormat[0].Video.Profile=High
Encode[0].SnapFormat[0].Video.Quality=6
Encode[0].SnapFormat[0].Video.BitRateControl=CBR

example:
ip/cgi-bin/configManager.cgi?action=setConfig&Encode[0].SnapFormat[0].Video.Quality=6



you will notice, that the size of the file will be much higher.

 

[alekk]

who is even writing so much and not just look into API doc ?

I would LOVE to get a copy of the API doc (my DM's are open!) ... in fact, I asked about it two weeks ago here! ;-)

Thanks a bunch @duplo for the tips - I'll try this later tonight.

 

[alekk]

I did some testing ... and while the change from VBR to CBR (and bumping the Bit Rate) resulted in a MUCH bigger JPEG, the overall quality wasn't that much better.

However, GREAT NEWS is that changing Encode[0].SnapFormat[0].Video.Quality=6 (from the default of 5) got rid of most of the blocky artifacts in the shadows - YEA!
So the image qualify of the couple hundred KByte JPEG is now comparable to the multi-MByte PNG ... which is what I would expect as I Photoshop is able to do a similar compression.

Note that Encode[0].SnapFormat[0].Video.Quality actually changes the selected quality in Pictures->Snapshot->Quality when you use the web interface ... you can do it there also. I thought I had investigated this earlier and not seen much difference, but I was wrong as I can clearly see the difference by fiddling with that ... not just in file size, but holy crap setting it to the minimum of 1 results in an impressive super-blocky image!

I had a few more options from what @duplo listed above in the output of action=getConfig&name=Encode but none of those seemed to make much difference.
One was Encode[0].SnapFormat[0].Video.QualityRange=6 ... which got me excited ... HEY, lets turn it up to 11! ;-)

So while I got an "OK" from setting that to various numbers (and it would "take" as seen in getConfig), it didn't seem to make any difference in the image quality nor could I set Encode[0].SnapFormat[0].Video.Quality to a higher value.

I'm curious to see what this looks during the day, but I would call this a nice improvement - thanks a BUNCH @duplo

HOWEVER, I still see the "lightening of the image" as seen above ... which makes the blacks look a bit grey. You can easily see that by grabbing a PNG from the Web Interface and comparing it to a JPEG from snapshot.cgi

Hikvision has a config option Image->Image Enhancement->Grey Scale that you can set to 0-255 or 16-235 ... and I'm wondering if something like the later is being applied by the Dahau to the JPEG's(?)