Feature: image I/O backend for JPEG and PNG types

[s-trinh]

see also #947

---

Some performance numbers on Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz CPU and Ubuntu 20.04:

• libjpeg-turbo is actually used, I would also recommend to install libjpeg-turbo instead of classical libjpeg
• current Simd code contains only optimized code for image writing, see: JPEG/PNG I/O performance ermig1979/Simd#183 (comment)
• libpng seems to not perform very well, but we are not comparing file size

[s-trinh]

Some self-review comments.

[s-trinh]

Should be updated to not throw an exception if the backend is not available but instead print an error and use either stb or simd as they are always available depending on the performance numbers.

Same for PNG.

[fspindle]

@s-trinh I found an issue in readPNG() with simdlib backend on color images

int main()
{
  vpImage<vpRGBa> I;
  vpImageIo::read(I, "/home/fspindle/visp-ws/visp-images/warp/cv_warp_affine_rot_45_color_NN.png", vpImageIo::IO_SIMDLIB_BACKEND);
  vpImageIo::write(I, "I.ppm");
  return 0;
}

If I modify

void readSimdlib(vpImage<vpRGBa> &I, const std::string &filename)
{
  size_t stride = 0, width = 0, height = 0;
  SimdPixelFormatType format = SimdPixelFormatRgba32;
  uint8_t* data = SimdImageLoadFromFile(filename.c_str(), &stride, &width, &height, &format);
  std::cout << "width: " << width << " height: " << height << " stride: " << stride << std::endl;
  ...

it prints

width: 558 height: 560 stride: 2240

For me stride = 558*4 = 2232.

It needs to be investigated before merging

[fspindle]

@s-trinh Thanks. I will merge this PR even if there remain some potential issues.

There is the testColorConversion.cpp test that seems to segfault sometimes (not always from what I understand) on mingw workflow. I suspect something wrong in BGRToGrey() when image size is 64x4. We can come back later to fix it if confirmed.

The sanitizers show also some issues when -fsanitize=thread is used.