A "fast" 2D image writer (
sight::io::bitmap::Writer) and its associated service (
sight::module::io::bitmap::SWriter) have been implemented. The writer uses NVidia CUDA accelerated JPEG / JPEG2000 encoding library: nvJPEG, if support has been compiled in and if a suitable GPU has been found. Alternatively,
libPNG can be used as CPU fallback. The performance should be better than VTK or even OpenCV because of direct API calls and avoided unneeded buffer copy.
⚠VTK SImageWriter support for 2D bitmap format has been removed. The support was anyway bugged as the image were saved upsode down.
- fix on
LocationDialog::getCurrentSelection()that erased the first char to return an extension from a wildcard filter. Now there is a
ILocationDialog::getSelectedExtensions()that returns a vector of extension, in case there are more than one extension from a filter.
- some small fix for high dpi displays in the GUI tester code.
libPNG backends have a
FAST and a
FAST compress faster and
BEST compress better, at the expanse of the speed. Options that affect quality are, for lossy codecs, set to the maximum the codec can provide.
Take a look at source code / doxygen comment and
io_bitmapTest for a clue how to use the writer and select the codec and the mode.
The service can be configured to select backends to use in several ways. Either you set the
enable attribute of
<backends> node to "all" or "cpu" or "gpu":
<config> <dialog description="Snapshot" policy="default" /> <backends enable="all" mode="best"/> </config>
Or you can specify explicitly the backend by name (i.e.: "libtiff", "libpng", "nvjpeg", ...). In all case you can also specify the mode, independently, for each backend:
<config> <dialog description="Snapshot" policy="default" /> <backends mode="fast"> <libtiff mode="best"> <nvjpeg2k> </backends> </config>
Take a look at
module_io_bitmapTest for more example.
Closes #950 (closed)
How to test it?
module_io_bitmapTest, preferably after having enabled
⚠Some bugs have been corrected and affect png (fast mode is now really faster ~74 -> ~150 FPS, but compress slightly less) and nvJPEG (also a lilltle bit faster).
1000 iterations on 3 images coming from real US imager (GE lossy jpg, Acuson 500 lossy jpg and lossless raw)
BITMAPWRITERTEST_LOOP=1000 ./io_nvjpegtest && cat ./fwTest.log
|CODEC||Size (Byte)||Time (ms)||FPS||PSNR|
|OpenCV PNG (F)||944226||31,19||96|
|OpenCV PNG (B)||805060||546,32||5|
For "lossy" codec:
- NVJPEG speed is from another galaxy, and its quality is considered as "visually" lossless with an average PSNR > 50.
- Pure CPU libjpeg-turbo can also be fast, but the maximum quality is inferior.
- OpenCV also uses libjpeg-turbo, but since it involves some additional conversion steps, it is logically a bit slower, but still quite good. (VTK - not listed here - is more than 5 time slower !)
For "lossless" codec:
- NVJPEG2K speed and compression ratio are, in overall, good, even if we cannot say it is the faster, nor the smaller. Still, it is nearly 3 time faster than the pure CPU openJPEG.
- LibTIFF, especially the "Best" variant (which use ZSTD as its compression engine) is a good alternative. It is the faster lossless CODEC, while still having some compression, and even largely beats openCV "Fast" PNG in both speed AND compression ratio. It is definitively my recommendation when CUDA is not available.
- LibPNG offers interesting compression ratio in "Best" mode and is even fast enough in "Fast" mode.
- OpenCV PNG is fast is really fast, but without great compression, and "Best" mode is horribly slow. No point to use it against LibTIFF "Best" mode when searching for speed, no point to use it against LibPNG when searching for compression ratio.
- Webp compress very well, it is the best in that regard for the lossless encoders, ...but very slowly. Just too slow for real time application. It could have its usage for long live storage, if its reading speed is fast enough (that must be tested...).