Vector graphics

[felixhorger]

Any chance we can get the in vivo image in the readme in higher resolution or even better as a vector graphic? 😄 I think it would then be easier to appreciate how well your reconstruction works. Take a look here.

[alexjaffray]

@mrikasper can you re-generate a high resolution or svg version of the in vivo figure?

[mrikasper]

Thank you for the suggestion, @felixhorger !

The source image is already high resolution (in fact, higher resolution than the reconstruction matrix size), so I am not sure how JOSS for the paper PDF handles the conversion. If you know of any pointers how to make the conversion less lossy, I would be happy to implement it.

For the README, we use a lower-resolution version of the image to reduce loading time (670kB instead of 9MB), but its resolution is still close to the actual resolution of the reconstruction matrix size.

With respect to vector graphics formats, if I understand them correctly, they would not improve the quality of the pixel-based reconstruction images themselves, but only the text and lines in between. File size might be a bit smaller, but in my opinion accessibility is higher with png, because many programs and platforms can read them.

All the best, Lars

[felixhorger]

Hi Lars! That's a good point with the size for the readme and accessibility. Like you say, using vector graphics would improve text and annotation, but not do anything for the images. I brought this up because I think it's good practice in science and if set up correctly can prevent the resolution problem to happen. But this is a personal preference, so if you want to stick to png that's fine by me ;)

Let me elaborate, because my previous comment was indeed not precise enough, sorry for that. I tried to say that the nominal resolution is not the effective resolution in the images, giving them a blurry appearance if you zoom in (even with a viewer that doesn't interpolate). This is because the images were interpolated beforehand I assume. Take a look at this screenshot made from ms-paint (which doesn't interpolate):

There you can see the pixels, but the effective resolution is worse than that (the nominal image resolution is clearly sub-millimeter, but the nominal resolution of the scan is probably 1mm?). You can specifically see it for the red line, which once was 1 pixel wide I suppose, before interpolation.

I think the resolution of the presented data should equal the nominal resolution of the scan, i.e. data is presented without any directly necessary post-processing.

Regarding how I would go about making the figure, something like:

fig, axs = PyPlot.subplots(2, 5)
axs[1,1].imshow(your_image; interpolation="none")
...
# use axs[2, 4] for a colourbar for the difference maps? and axs[2, 5] for the Ref Edge plot
PyPlot.savefig("myfig.png"; dpi=200) # dpi value not tested, can be lower to save memory, or higher to prevent misalignment

Adding the braces is possible I guess, but difficult. I suggest instead using the titles No correction (A), + B0 map (B), +GIRF Kxyz (C), ... and the titles of the difference maps |A - B| x 5 etc.

Thanks and best wishes, Felix

[mrikasper]

Dear Felix @felixhorger,

Thank you for this detailed response and the example code.

I understand now better what you suggest: Let the reader decide on what interpolation is used for displaying a pixel matrix, rather than the author.

I think ideally this is done on a programmable level like you suggest with your coding snippets. However, our ethics does not allow to share the data for the in-vivo figure at the moment, so this would not really be possible in and end-to-end way.

What we could do instead is to do what you suggest for the phantom figure and save it (or its components) as .svg. Does this sound like a good compromise?

All the best, Lars

[felixhorger]

Dear Lars,

thanks for elaborating! I think the phantom scan is good in terms of the nominal resolution being equal to the effective one (when I zoom-in to the pixel level there is no blurring visible). I can for example spot the one-pixel-wide intensity modulations around the edges of the phantom internals in the second subplot of the phantom figure. If you compare that to the snapshot I put above you'll notice that the pixels are more fine grained than the structures in the image, i.e. the effective resolution is worse than the nominal.

My proposition does not need public access to the data or any interaction with the user/reader. To clarify what I think happened: the images were reconstructed, plotted into pngs (possibly first interpolation), then imported into another program (PowerPoint/Word?) to add the brackets and labels (possibly second interpolation) and then exported as a pdf or png (possibly third interpolation). What I would like is to make sure all these steps do nearest neighbour interpolation instead of bilinear (or similar). Let me provide another snippet which shows an exaggerated example, hopefully supporting my point better

using PyPlot
plt.ioff()

image = zeros(8, 8)
image[:, 4] .= 1
image[4, 5] = 2

fig, axs = plt.subplots(1, 2, figsize=(7, 3))
axs[1].imshow(image, interpolation="bilinear")
axs[2].imshow(image, interpolation="nearest")
foreach(ax -> ax.set_axis_off(), axs)
plt.savefig("test.png", dpi=20)

and then you open test.png in ms-paint, rescale by 400%, which should give this

showing that on the left, where linear interpolation is used, a blurring is introduced, and the effective resolution is obviously worse than the nominal one. On the right, the image matrix still has the same size as on the left, but it's obvious what the effective resolution is, i.e. I can make out the original pixels of the 8x8 data image.

Apologies for dragging this out, but I think the power of your pipeline would be more appreciable if you can see the same level of detail you have in the phantom scans also in the in vivo images. I see this problem with interpolation of lower-res images quite often in publications or ISMRM abstracts, so I want to develop a best practice for displaying images in our field.

All the best, Felix

[alexjaffray]

We have reviewed the issue and it will take some time to regenerate the figure, however we will keep in mind to follow a pixel-preserving image generation pipeline in the future. In the broader list of issues identified by the review, it is minor and does not really reduce the scientific value of the submitted work, so we will address it once the other issues are resolved.

[alexjaffray]

Closing as it is of lower priority and unlikely to be solved very soon for the README image