uiimage introduces artifacts? How to fix?

I am building an application using App Designer and I am using images (Type = 'uiimage') and using the ImageSource property to display data. I am seeing artifacts on the GUI that are not in my data.

I can also produce the same behavior with a plain uiimage from the console.

img = ones(160, 160, 3, 'uint8') * 128;
img([48, 65], 1:4:end, :) = 0;
img([48, 65], 2:4:end, :) = 0;

fig = uifigure;
im = uiimage(fig);
im.ImageSource = img;
im.Position = [ 100, 100, 160, 160];
im.ScaleMethod = 'none';

The result from this is shown here:

Looking closely at the dashed lines shows the artifacts:

These look to me like jpeg artifacts. I am using ScaleMethod 'none' to try to rule out any resampling effects. In my application I am using a fixed size image that exactly matches the data size so it should not be performing scaling.

One of the purposes of my application is for users to closely scrutinize an image to look for artifacts in the underlying data, so it is important that the MxNx3 uint8 array is faithfully produced on the screen.

A "regular" figure with imshow does not show artifacts:

fig2 = figure;
imshow(img);

What's the best way to show the image in my application without artifacts?

[Nitin Kapgate]

I tried to reproduce the issue at my end using the above code, but I didn't find any artifacts in the image displayed using uiimage (verified in R2020a version of MATLAB)

Are you still facing this issue? Could you let me know your MATLAB version?

[Jamie]

Thank you, I am using 2019a. I can try 2020a and see if this has already been fixed. I'll report back what I find.

[Jamie]

I have installed Matlab 2020b and I am seeing the same artifact with uifigure + uiimage.

This is the result from my 'ver' command:

-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.9.0.1570001 (R2020b) Update 4
MATLAB License Number: #######
Operating System: Microsoft Windows 10 Enterprise Version 10.0 (Build 19042)
Java Version: Java 1.8.0_202-b08 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------
MATLAB                                                Version 9.9         (R2020b)
Image Processing Toolbox                              Version 11.2        (R2020b)
MATLAB Compiler                                       Version 8.1         (R2020b)
Parallel Computing Toolbox                            Version 7.3         (R2020b)
Signal Processing Toolbox                             Version 8.5         (R2020b)

Also I notice your display says "Figure 1" with a toolbar. I would reemphasize that a regular figure + imshow works fine, and only the uifigure + uiimage has the issue.

You said you used uiimage, and I thought perhaps a regular figure + uiimage might be informative but apparently they do not work together.

Answer 1

[Nitin Kapgate]

Thank you @Jamie for bringing the issue of artifacts in the uifigure + uiimage workflow to my attention.

After revisiting the issue again, I could see artifacts being displayed when the image is displayed using the uifigure + uiimage workflow.

I have brought this issue to the concerned people and the issue might be resolved in future releases.

[Jamie]

Thank you.

[Nitin Kapgate]

As a workaround, you can serve cdata as file:

imwrite(img, 'imgFile.png');
im.ImageSource = 'imgFile.png'

Answer 2

[DGM]

Interesting that this had already been reported before I reported it as a bug.

The reason for these artifacts is simple. Whenever uiimage() is given a filename, it reads the image using imread(). That means that it can read a broad range of filetypes and it can support indexed images and alpha content.

The other way to use uiimage() is to feed it image data from the workspace. In this case, it takes your image, writes it to disk as a low-quality 4:2:0 subsampled JPG, then it reads it back using imread(). Not only is the image unnecessarily damaged, the fact that it uses JPG means that it can't actually display indexed or transparent images.

This thread is where I first figured this out. The followup comments describe the problem, I give some demonstrations, and demonstrate a workaround.

https://www.mathworks.com/matlabcentral/answers/2046100-loading-images-without-compression#comment_2960722

As to whether this constitutes a bug, I'll reiterate what I said in the bug report. Are heavily lossy image facsimiles acceptable for display purposes? No. Not when the purpose of the displayed image is to monitor a technical image editing process and examine its details and exact pixel values. If Photoshop or GIMP or MSPaint wouldn't do it, then a technical environment like MATLAB shouldn't. The fact that it's trivial to modify the support files to use PNG for the temp file is enough for me to assert that there's no justification for the damage done to the working image. That's a bug.

The question remains whether there's any justification for using any tempfile. Even if there is, PNG would allow uiimage() to support transparency and indexed images from the workspace -- but since everything was written around using garbage JPG, there isn't any in place to handle the required extra arguments. I'm doubtful that a tempfile can't be avoided.

[Jamie]

Recently (about a few months ago) I discovered uiimage is also horrendously slow on some computers. I had created a compiled application with several uiimage displays updating from an image source a few times per second, and on some computers it crawled at a few seconds per frame, making the application unusable. (I'm still using 2019a because all the users have the 2019a runtime installed.)

I had to evict uiimage and replace it with a panel containing an axis, drawing the image using imshow. Then it ran full speed.

I didn't understand why it should be so slow, or computer-dependent, but it makes sense if it is writing a file. It did not occur to me that it might be hitting the filesystem, so thanks for pointing that out.

[DGM]

Oh wow. I hadn't even given speed a consideration, but yeah. That would be a great way to slow things down. I would suspect that the tempfile directory is on ramdisk, but maybe they aren't always. Either way, I don't see any reason for all the overhead of encoding/decoding.