Sequence of PNGs, getting interlaced artifact

Operating system: win10
Slicer version: 4.11.20200930

Expected behavior:
I follow this one minute tutorial (https://www.youtube.com/watch?v=BcnpzYE8VO8)
and expect the 3d model.

Actual behavior:
one of the slices gets an interlaced artifact as you can see here:

I don’t understand why the image (10) generates that pattern,
give that it’s not particularly different than the rest.

you can check my 20 pngs dataset here:

I’m just a random guy who got an MRI of my head, I’m sorry if this is too basic. Thank you.

png are stored in RGB color space (3 images one for each color), when you load the png you need to convert to grayscale first. How did you plan to import your png in the first place?

1 Like

I follow this one minute video, step by step (https://www.youtube.com/watch?v=BcnpzYE8VO8)

I get the 3D model but just one slice in particular gets this weird interlaced repetition pattern that you can see on the screenshot at the red panel (bottom left) and on the 3D model.

I tried with diferent segments of the sequence and it always happen at the same image, and there’s nothing particularly different about it.

All images in the stack must be the same. image (12).png has only 3 components (RGB) while all the others have 4 components (RGBA). It would have been nicer if ITK (image processing library that Slicer uses for image reading) rejected this data set instead of showing a corrupted image - I’ve filed a bug report for you (see here).

To fix this problem, you need to save all the screenshots with the same settings (either RGB or RGBA works fine).

Note that 8-bit screenshots are not suitable for capturing CT data sets, as in the image that you get the noise is either magnitudes higher compared to the original 12-bit image, and/or details in high and/or low intensity regions are lost. You don’t have very accurate information on pixel size either.

Many of the web DICOM viewers do not allow export of the actual data set to “prevent” leaking of patient data without permission, but the study protocol should allow you to obtain properly anonymized data sets that are not compromised in image quality. It is worth going through the process of getting proper images, as any results that you get from such low-quality 8-bit screenshots will not be representative of the results that you could get from the actual clinical images. If you don’t have a study protocol set up for this project then you are probably better off with using data from open image databases.

1 Like