Color information lost when writing certain file formats

[gab1one]

Writing multi-chanel images .jpg and .png files with the image writer node results in those images being single channel instead of multi channel (gray scale).

Steps to reproduce:

• get the Image reader example workflow from the example server: tutoknime://EXAMPLES/099_Community/02_ImageProcessing/Tutorials/Node%20Tutorials/01_ImageReader/01_1_ImageReader
• Write the read images (3 channel RGB) with the image writer node as .jpg files.
• read those images with the image reader:
• Input Image:
• result Image

[beschu]

I created a workflow that checks for this bug and placed it on mekur. It is named: color-info-lost-3channelRGB-jpg-issue303

I took the above mentioned image series and tested it: Writing as a jpg is lossy, hence we need measurement to see if images are the same regardless of lossy writing.

My idea was:

• Subtract the original and written image, apply convolution and then a global thresholder with manually set value (around 55) to hopefully get an image filled with zeros
• Compare to a generated all-0 image and if they are the same then everything is ok. If they are not the same it most likely isn't the .jpg compressions fault but the fault, that some color info is lost or a channel is missing.

With that approach i couldn't reproduce this bug and everything seems to be fine.

[tibuch]

Thanks!

[dietzc]

I don't understand. The problem seems to be that a dimension is either lost or added, not about lossy content at all. Can you confirm that the dimensionality of the written image and of the image read back to KNIME are the same?

[tibuch]

@dietzc @beschu and I looked at the workflow of @beschu. The written jpg files get read again and there are no issues with the dimensions. Looks like this bug got fixed somehow or @gab1one meant something different?

[tibuch]

@beschu and I just encountered the following problems:

• read png (X, Y, Channel) -> write png (X, Y, Time) (Issue #160)
• read png (X, Y, Channel) -> write jpg (X, Y) (maybe this issue?)

[dietzc]

What we read shouldn't be an issue at all, as we transform the image (at the moment) anyway to our internal data-format. The dimensionality of the image after having it read it is way more important. Can you therefore please reproduce the problem with the Image Generator (which creates exactly the same type of images you would get when reading in the png) and create two reproducing workflows + open issues accordingly, if not already opened? All this cross-referencing of issues gets a bit confusing.

[tibuch]

I agree that not reading the images is the problem. As far as I can tell it is a writer problem. We only use the readers to see the result of the writer.

[beschu]

I created the two reproducing workflows and opened the issues here:

446 Write UnsignedByteType as jpg

447 Write UnsignedByteType as png

[dietzc]

can we close this issue then?