Save JPG images faster

[JohnnyDoe771]

Hi Ben,

I disabled the folder directory and its still saving images very slow.

[Ben]

---

@JohnnyDoe771 wrote:

Hi Ben,

I disabled the folder directory and its still saving images very slow.

---

No, put a diagram disable around your code that interacts with the disk and that included saving etc. I realize that is not your final desire but it will tell you if the slow down is due to the disk actions or elsewhere.

If it runs as fast as the acquisition you will know the bottleneck is the disk and a SSD may be needed. If it not the disk, you can focus on other things.

"divide and conquer"

Ben

[Bob_Schor]

By now, you've probably made several changes to your code.  These comments are based on the code attached with your original post.

• What is the point of the Queue?  You appear to use it as a "clock", which makes no sense.  Queues (and Channel Wire Streams) are self-clocking -- they wait (patiently) until there's something there to process.  You don't ever use the information of the Queue, so just eliminate it.
• You have an Image Display in your Producer loop.  This may be OK, but I'd move it out to the Consumer (or diagram-disable it and see if that changes the fps in the Producer).
• Why are you copying a buffer inside the Producer loop?  I think you are moving all those pixels and putting them in another section of memory, and for what?
• If you compute the size of your Image, it's about 5 MB.  I take it that the 715 kB that you report is the size of a .jpg file, a 7-fold compression factor (not bad).  You know that with compression comes (some) data loss -- I don't recall if you can alter the compression factor that LabVIEW uses, but you should try other formats, as well.  Compressed images are faster to write, but it takes time to compress (and I don't know the tradeoffs -- do an experiment).
• The other thing you can do is make a Video, i.e. create an AVI file using Motion JPeg.  Again, I don't know the details on the compression, but it may be efficient.

Bob Schor

[rolfk]

On current processors or unless you have a really devilish fast SSD with the bus connection that can sustain its speed, compression is almost always cheaper performance wise than the IO bottleneck. So compressing data before writing it to disk not only saves disk space but also speeds up the IO operation. LabVIEW compresses large parts of its internal VI parts mainly for this reason as zlib compressed streams on disk!

[drjdpowell]

Minor point on "Producer-Consumer" and DAQmx.  A DAQmx acquisition task is already a Producer, with LabVIEW the Consumer, with an image buffer in between, so coding another Producer loop gains one nothing and adds complexity and (minor) overhead.

[Eric1977]

This is an interesting thread. I'd like to know how the final VI looks.

[JohnnyDoe771]

Hey Eric,

The conversation is continuing at in this link: https://forums.ni.com/t5/LabVIEW/How-to-Optimize-Camera-Speed-fps/td-p/3958048/highlight/false/page/...

There's also my most recent code uploaded there 🙂