Add JpegCompressionDistortion CPU and GPU operators

[jantonguirao]

Signed-off-by: Joaquin Anton [email protected]

Why we need this PR?

Pick one, remove the rest

• It adds a new operator needed to generate JPEG-like distortion

What happened in this PR?

Fill relevant points, put NA otherwise. Replace anything inside []

• What solution was applied:
  Added a JpegCompressionDistortion operator, both GPU and CPU implementations.
  The CPU version uses OpenCV imencode/imdecode
  The GPU version uses a custom CUDA kernel
• Affected modules and functionalities:
  New operator
• Key points relevant for the review:
  All
• Validation and testing:
  Python tests added
• Documentation (including examples):
  Docstr

JIRA TASK: [DALI-1932] [DALI-1941]

[JanuszL]

Suggested change

	Any values outside the range 1-99 will be clamped.)code",
	Any values outside the range 1-95 will be clamped.)code",

?

[jantonguirao]

It was actually the other way around. I fixed it now

[mzient]

I think that you can set quality 100 in many graphics editors. Also, I predict that having this parameter as float would be more convenient.

[jantonguirao]

Both libjpeg and OpenCV use integer for the quality factor. I will check if 100 makes sense in the current formula.

[mzient]

Wouldn't that work?

Suggested change

	cv::Mat in_mat(sh[0], sh[1], CV_8UC3, (void*) in_view[sample_idx].data); // NOLINT
	cv::Mat out_mat(sh[0], sh[1], CV_8UC3, (void*) out_view[sample_idx].data); // NOLINT
	cv::Mat in_mat(sh[0], sh[1], CV_8UC3, in_view[sample_idx].data);
	cv::Mat out_mat(sh[0], sh[1], CV_8UC3, out_view[sample_idx].data);

[jantonguirao]

it doesn't work (there are other overloads)

[mzient]

Isn't there a problem with the fact that our shape has int64 extents? What about this?

Suggested change

	cv::Mat in_mat(sh[0], sh[1], CV_8UC3, (void*) in_view[sample_idx].data); // NOLINT
	cv::Mat out_mat(sh[0], sh[1], CV_8UC3, (void*) out_view[sample_idx].data); // NOLINT
	int h = sh[0], w = sh[1];
	cv::Mat in_mat(h, w, CV_8UC3, in_view[sample_idx].data);
	cv::Mat out_mat(h, w, CV_8UC3, out_view[sample_idx].data);

[jantonguirao]

The main problem seems to be:

jpeg_compression_distortion_op_cpu.cc:69:59: error: invalid conversion from ‘const void*’ to ‘void*’

[mzient]

The problem is const - use const_cast<void*> then (or const_cast<uint8_t*> or whatever our format is).

[jantonguirao]

done

[szalpal]

IMHO, there should be a clear explanation, what is a "JPEG-like distortion"

[mzient]

Suggested change

	.DocStr(R"code(Produces JPEG-like distortion in RGB images.
	The level of degradation of the image can be controlled with the ``quality`` argument,
	)code")
	.DocStr(R"code(Introduces JPEG compression artifacts to RGB images.
	JPEG is a lossy compression format which exploits characteristics of natural images and human visual system to achieve high compression ratios. The information loss originates from sampling the color information at a lower spatial resolution than the brightness and from representing high frequency components of the image with a lower effective bit depth. The conversion to frequency domain and quantization is applied independently to 8x8 pixel blocks, which introduces additional artifacts at block boundaries.
	This operation produces images by subjecting the input to a transformation that mimics JPEG compression with given ``quality`` factor followed by decompression .
	)code")

?

[jantonguirao]

done

[jantonguirao]

!build

[dali-automaton]

CI MESSAGE: [2260239]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [2260239]: BUILD PASSED

[mzient]

It's a nitpick, really, but I think that a more realistic value would be 90. 80 is usually considered quite poor, 95 typically requires considerable magnification to see any distortion. Perhaps there shouldn't be any default value?

[jantonguirao]

It's the default quality used in OpenCV and libjpeg-turbo, I believe.

[jantonguirao]

!build

[dali-automaton]

CI MESSAGE: [2263323]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [2263323]: BUILD PASSED