ENH: add a buggy jpge baseline where DICOM info conflict with jpeg info

diff --git a/Baseline/JDDICOM_Sample2-dcmdjpeg.png b/Baseline/JDDICOM_Sample2-dcmdjpeg.png
new file mode 100644 (file)
index 0000000..de70ecb
Binary files /dev/null and b/Baseline/JDDICOM_Sample2-dcmdjpeg.png differ

diff --git a/Baseline/JDDICOM_Sample2.png b/Baseline/JDDICOM_Sample2.png
new file mode 100644 (file)
index 0000000..156a61f
Binary files /dev/null and b/Baseline/JDDICOM_Sample2.png differ

diff --git a/JDDICOM_Sample2-dcmdjpeg.dcm b/JDDICOM_Sample2-dcmdjpeg.dcm
new file mode 100644 (file)
index 0000000..8b29fdd
Binary files /dev/null and b/JDDICOM_Sample2-dcmdjpeg.dcm differ

diff --git a/JDDICOM_Sample2-dcmdjpeg.txt b/JDDICOM_Sample2-dcmdjpeg.txt
new file mode 100644 (file)
index 0000000..3f9294e
--- /dev/null
+++ b/JDDICOM_Sample2-dcmdjpeg.txt
@@ -0,0 +1,16 @@
+This is not the decompression gone wrong, this is the image being incorrectly
+encoded. The problem is that the JPEG bitstream in this image is in YCbCr
+color space, but DICOM PhotometricInterpretation claims that the color space
+is RGB.
+
+In dcmdjpeg, you have a command line option --conv-always that enforces a
+conversion from YCbCr to RGB and another option --conv-lossy that enforces
+this conversion for lossy JPEG only. Both solve the problem with this image.
+
+Both option are not enabled by default, though, because they would cause some
+legitimate DICOM images to be displayed incorrectly. We prefer that the
+default behaviour of our tools is to correctly process correct data. Options
+that are needed for incorrect objects and would cause certain correct objects
+to be processed incorrectly (even if only in rare cases) are never enabled by
+default.
+

diff --git a/JDDICOM_Sample2.dcm b/JDDICOM_Sample2.dcm
new file mode 100644 (file)
index 0000000..0dcc5a7
Binary files /dev/null and b/JDDICOM_Sample2.dcm differ