Snapshot quality

nothreat

n3wb
Jul 5, 2020
16
2
USA
Hello,

I have my cams setup to take a snapshot ever 15min and save to a folder so I can make a time-lapse at the end of the year. Problem is the quality of the snapshots aren't very good atm.

In BI under Record, I have JPEG snapshot checked and Quality 100%.

If you take a look at the side by side shots attached the better quality image was taken with windows 10 screen capture the other is BI snapshot.

Why are my snapshots so low in quality? Is there another setting that I'm missing?
 

Attachments

  • Blue Iris 7_9_2020 10_28_07 AM.png
    Blue Iris 7_9_2020 10_28_07 AM.png
    3.9 MB · Views: 62
  • Blue Iris 7_9_2020 10_28_07 AM_Snapshot.jpg
    Blue Iris 7_9_2020 10_28_07 AM_Snapshot.jpg
    174.6 KB · Views: 62
Yes I am
 

Remove the substream and see if you get full resolution. I was having trouble with snapshots when using substreams on my front door camera. It was sending low resolutions pics when movement was detected to Aitool. This has not been fixed as far as I know... One of the drawbacks of using the substream feature.
 
I need to have sub-stream enabled to keep my cpu usage down. I hope this gets fixed in the future.

Thanks for the reply!
 
Yes I too found that using substreams means that the snapshots are captured at the substream resolution.

Report it as a would be nice to have feature to support, the more that report it the more likely that it might be introduced as a new feature.
 
This was answered by another forum member that has a lot of great knowledge about the program:

You need to turn off the sub stream. This is one of the ways a sub stream is a compromise.

While it is not impossible for Blue Iris to begin decoding the main stream each time this snapshot is needed, it would be complex and bug-prone. In cases like yours where a lot (all) of your cameras are configured to save a snapshot at the same interval, then it would cause tremendous load spikes that could easily overwhelm the system and cause instability.

That would require quite a bit of work on Blue Iris's part. It is already decoding the sub stream so when the trigger happens it can easily just take one of the decoded frames and compress it as jpeg. In order to save a main stream frame as a jpeg, Blue Iris would need to seek back to the previous i-frame in the main stream, decode that, and then decode all the frames from there until the trigger point. This would add a significant resource usage spike at the least (possibly also a lot of new bugs).

I would recommend not configuring the sub stream for any cam where it is going to affect your usability, and in the case of your LPR cam it clearly does.
 
This was answered by another forum member that has a lot of great knowledge about the program:

I remember posting on that thread and yes I disabled substreams on the cams that take just pictures through trail and error before seeing that reply but it would still be worthwhile asking if it could/would be possible.
 
I sent Bi support an email about this.

Having the sub-stream on is a must for me.

The snapshot feature was a key feature for me for buying this software.

Seems if the snapshots are spaced out and not all snapped at the same time maybe would lessen the load.
Add a sec to each cam 15m:01sec 15min:02sec, if the snapshot feature is on have the shots taken in intervals of 1sec from each other not all at the same time.
 
Couldn't a user just clone the camera without the substreams and set the snapshots on the cloned camera? (Hide the clone camera from view, so you don't have duplicates in your views). This way the sub stream can be used by the original camera and gain all the benefits from using the sub stream and get full resolution snapshots.

I think it will work the way I expect, although admittedly I have not tried it in this exact manner on my own system.
 
I think the issue there (if I’m not mistaken) is that now you have a clone streaming the main stream and therefor using all the system resources of the original camera had you just eliminated the sub all together
 
It was added to an update after substreams where introduced:

From the help file.
5.3.3 - October 1, 2020
When using dual-streaming, JPEG images will be created from the main-stream instead of
the sub-stream where possible. Rather than fully spooling up main-stream decoding, the
software uses the direct-to-disc pre-trigger frames buffer to synthesize these images. This
means you should specify at least enough pre-trigger time on the Record tab to span the
key-frame interval for your main-stream.

And yes, the issue of the clone camera without the substreams then makes it not a clone and motion detection will be made from the mainstream then and then you are pulling two video streams and actually using more CPU.
 
It was added to an update after substreams where introduced:

From the help file.
5.3.3 - October 1, 2020
When using dual-streaming, JPEG images will be created from the main-stream instead of
the sub-stream where possible. Rather than fully spooling up main-stream decoding, the
software uses the direct-to-disc pre-trigger frames buffer to synthesize these images. This
means you should specify at least enough pre-trigger time on the Record tab to span the
key-frame interval for your main-stream.

And yes, the issue of the clone camera without the substreams then makes it not a clone and motion detection will be made from the mainstream then and then you are pulling two video streams and actually using more CPU.
this worked perfectly, thank you
 
And yes, the issue of the clone camera without the substreams then makes it not a clone and motion detection will be made from the mainstream then and then you are pulling two video streams and actually using more CPU.

I'm glad this has been corrected/fixed with the images coming from the main stream instead of the substream. Clearly this is the correct method to use.

That being said, using a clone camera wouldn't have increased CPU usage of the computer because the motion detection system isn't used for timed snapshots like the OP wants to get. If the system hadn't been updated to correct the original problem, this would have been a viable alternative.
 
I'm glad this has been corrected/fixed with the images coming from the main stream instead of the substream. Clearly this is the correct method to use.

That being said, using a clone camera wouldn't have increased CPU usage of the computer because the motion detection system isn't used for timed snapshots like the OP wants to get. If the system hadn't been updated to correct the original problem, this would have been a viable alternative.

Nope - once you remove the substream, it is no longer a cloned camera.

I just tested it to confirm something hasn't changed in a recent update and the * disappeared (the *indicates it was a clone) and the Mbps went up accordingly.

I simply removed the substream and had no motion detection selected.
 
Last edited:
  • Like
Reactions: looney2ns
That being said, using a clone camera wouldn't have increased CPU usage of the computer because the motion detection system isn't used for timed snapshots like the OP wants to get.

I think that is incorrect. Decoding main streams is what uses a lot of CPU time. Motion detection is very little by comparison. If you cloned a sub-stream-enabled camera and disabled the sub stream on the clone, then you would be adding the full CPU cost of one main stream.
 
  • Like
Reactions: looney2ns