Display Images

[RoyiAvital]

I have 2 questions:

1. Is there a way to display an image in 1:1 manner? Namely each pixel on the screen matches a single pixel on the image itself (No interpolation of the displayed data).
2. I work with images like in MATLAB (Not using the Julia Images data structure). Could a support for those be added?
   Namely support m x n matrices with values in [0, 1] (AbstractFloat) or <: Unsigned and m x n x 3 with values in [0, 1] (AbstractFloat) or <: Unsigned?

[mbaz]

1. Not exactly 1:1, because gnuplot does not support setting the size of the plot itself. You can set the size of the "canvas", but that includes margins, tic labels, etcetera. Probably the closest you can get is something like

i = randn(100,100)
plot("set size ratio -1", "set autoscale fix", i, "with image pixels")

(using the dev branch syntax).

2. Plotting a matrix is supported: just use imagesc or specify with image. Regarding a 3-D array, I'm not sure how you would plot that. You can of course slice it into 2-D matrices and plot that. Could you clarify how you would like to plot the 3-D arrays?

[RoyiAvital]

When I say 3D I mean RGB image (m x n x 3).

For some reason, on Windows, the plots doesn't look like on documentation even after updating the ini file.

[mbaz]

Just to make sure I understand: what do you get if you run this example on Windows? https://mbaz.github.io/Gaston.jl/stable/2dplots/#RGB-image-1

[RoyiAvital]

I will show you a simple plot from the documentation as I'm trying to avoid Julia Images packages (I prefer Matrices for images).

This is my wgnuplot.ini:

When I run (From https://mbaz.github.io/Gaston.jl/stable/introduction/):

t = 0:0.01:1
plot(t, sin.(2π*5*t),
     linecolor  = :coral,
     Axes(title = :First_Plot)
    )

This is what I get:

I am on Windows 10, Julia 1.9.1 and gnuplot 5.4 patchlevel 8.

[mbaz]

According to gnuplot's user manual, on Windows it will look for the file %APPDATA%\GNUPLOT.INI. Can you try renaming your startup file and making sure it's in the right location?

[RoyiAvital]

Yep, was just about to report this.
It seems strange. The GnuPlot creates the wgnuplot.ini yet seems to ignore it (Or maybe use it only in terminal).

I created gnuplot.ini and it made things looks like the demo!

[mbaz]

Yeah, creating and ignoring wgnuplot.ini sounds like a bug.

[RoyiAvital]

OK, So we're making progress.

Now, for grayscale image I use imagesc(rand(500, 500), Axes(palette = :gray, auto="fix", size="ratio -1", title = "\"My Image\"");.
Anything I can do to make 1:1?

From your suggestion plot("set size ratio -1", "set autoscale fix", i, "with image pixels") I can see the fix and ratio. What about with image pixels?

I understand that for images they should be CxHxW in the range [0, 255].

[mbaz]

As described in the documentation, "with image pixels" reduces the amount of processing (like antialiasing, interpolation, etc) that the terminal does before displaying the image.

For RGB images, they should be represented as 3xHxW matrices. The color range is indeed 0 to 255.

grayscale = rand(100,100);
imagesc(grayscale, Axes(palette = :gray, auto = "fix", size = "ratio -1"))
rgb = round.(Int, rand(3,100,100).*255);
imagesc(rgb, Axes(auto = "fix", size = "ratio -1"))

[RoyiAvital]

I asked how can I have the effect of with image pixels in the current version. Which property of the Axes?

[mbaz]

It's not an Axes property, but a plot style. Version 1.1.0 allows this but is a bit awkward. The upcoming version does not have this problem. Anyway, the solution for grayscale images is:

img = rand(100,100);
plot(1:size(img)[2], 1:size(img)[1], img, with = "image pixels")

For RGB images (3-D matrices), just replace image with rgbimage.

[mbaz]

img = rand(300,300);
plot(1:size(img)[2], 1:size(img)[1], img, with = "image pixels",
     Axes(lmargin = "at screen 0",
          rmargin = "at screen 1",
          bmargin = "at screen 0",
          tmargin = "at screen 1",
          tics = false))
save(term = "pngcairo size 300,300", output = "1to1.png")

[RoyiAvital]

I will check it and get back.
It might be that you solved me a big problem I had with Julia until now :-).

[mbaz]

That'd be awesome. Let me know how it goes.

[RoyiAvital]

OK, This is what I am running after removing the offset from the ini file:

numRows = 20;
numCols = 20;
mI = rand(numRows, numCols);
plot(1:numCols, 1:numRows, mI, with = "image pixels", Axes(palette = :gray, lmargin = "at screen 0", rmargin = "at screen 1", bmargin = "at screen 0", tmargin = "at screen 1", tics = false))
save(term = "pngcairo size $(numCols),$(numRows)", output = "1to1.png")
round.(mI .* 255)

I get a 20x20 PNG file which I load to MATLAB.
On MATLAB I can see that the first column and row are 0, so something from the axes is left.
Moreover, the really strange thing here, the values don't match what I see on Julia:

It might be color profile or something like that, I am not sure.

Another thing is the output window of Gaston.
Unless I add size = "ratio -1" it uses arbitrary window (Size of the last opened one).
Yet when I do use size = "ratio -1" I get a colorbar which ruins everything.

[mbaz]

You can supress the colorbar by adding colorbox = false to Axes.

Regarding the PNG colors: Since the image you show is much larger than 20x20, I suspect the upsampling algorithm is performing some sort of averaging. Can you try with a larger image (say, 400x400) so it can be displayed without upsampling?

Regarding the all-zero first row and column, it may be a gnuplot bug. What I would try first is to set the matrix's first row and column to a fixed number (say, 0.5), and see if you can get it back when loading the PNG.

[mbaz]

(Note that in questions like this, you and I have the same resources -- I'm not an expert in everything related to gnuplot)

This is the best I've been able to do: a 300x300 matrix on a 300x300 PNG file:

There is a margin (between the black line and the plot) that means the data is not plotted exactly 1:1. I haven't figured out how to remove that margin. If you can't find how in the manual, it may be worth it to ask the authors. I've found they're generally responsive.