dpi on backends

[mkborregaard]

1. The dpi of the pyplot backend has changed with the shift to matplotlib 2.0. Plots should adjust accordingly.
2. gr and plotlyjs both ignore the dpi argument
3. The pyplot backend seems to have the dpi argument backwards:

using Plots; pyplot()
scatter(1:10,1:10) # dpi = 100 as default

scatter(1:10, 1:10, dpi = 150) # This should result in smaller elements

An earlier merged PR claimed to fix this (https://github.com/JuliaPlots/Plots.jl/pull/517/files) but it hasn't, it seems. It did do something, though, reverting that PR gives

scatter(1:10, 1:10, dpi = 350)

[ma-laforge]

Hi @mkborregaard:

From my own experiments: I don't think sufficient thought was ever put into the DPI question.

It seems to me that DPI does not really have a place the way Plots.jl was defined (it uses different knobs to control how plots look):

AFAIK:

• DPI is a way to relate pixel/image size to physical dimensions (ex: 1000 pixels represents 10 cm) - thus the typical units "pixels per inch".
• Plots.jl defines the canvas size (w, h) in "pixels", and I think the intent is for the user to specify line widths, etc in "pixels" as well. That's how the Cairo backend works by default - but I admit I could not really confirm if that was how Plots.jl was meant to operate.
• On the other hand: fonts are typically drawn in "points" (a physical unit measuring 1/72 inch) - so the font size should, in theory be affected by DPI. In Cairo, I believe there is a default or implied DPI value used to control font sizes somewhere - but I personally have never changed it.

When would I expect Plots.jl to use DPI?
Ignoring font sizes: I would expect DPI to be used only if a user wanted to export a pixel-based plot image by specifying (w, h) using physical dimensions like inches, or centimeters. In that case, you kind of need a DPI value in order to figure out how many pixels to use.

EDIT: Conversely, the DPI value could simply be added to image as an informative-only meta-tag to tell programs like word processors how large to make the image when it first gets inserted in the document. However, this value would not, affect the sizes of the symbols or line widths relative to the total image size.

FYI: I still have an open issue trying to understand the intent of DPI in Plots.jl: #653

Once I understand what Plots.jl intended backends to do with the DPI value, I would probably be able to help fix the PyPlot issue.

[tbreloff]

Who says there was anything intended? :) This is a tricky item to generalize, but we already have the components needed. I agree that unitless numbers generally correspond to points for fonts and pixels for other things. Ideally the sizes could be any unit and calculations would lazily wait until final output. This is what Measures is for, and one of the best parts of Compose and family. They take the convention that mm is the "base" unit. I generally prefer that pixel is the base unit because my output is generally to the screen. Neither is inherently wrong, but correctly converting between units is a good thing to get right. Btw... PyPlot sucks for consistency... did I mention I want to deprecate it?

…

On Wed, Mar 15, 2017 at 6:54 PM ma-laforge ***@***.***> wrote: Hi @mkborregaard <https://github.com/mkborregaard>: From my own experiments: I don't think sufficient thought was ever put into the DPI question. It seems to me that DPI does not really have a place the way Plots.jl was defined (it uses different knobs to control how plots look): AFAIK: - DPI is a way to relate pixel/image size to physical dimensions (ex: 1000 pixels represents 10 cm) - thus the typical units "pixels per inch". - Plots.jl defines the canvas size (w, h) in "pixels", and I *think* the intent is for the user to specify line widths, etc in "pixels" as well. That's how the Cairo backend works by default - but I admit I could not really confirm if that was how Plots.jl was meant to operate. - I admit: fonts are typically drawn in "points" (a physical unit measuring 1/72 inch) - so a DPI ratio should, in theory be affected by DPI. In Cairo, I believe there is a default or implied DPI value used to control font sizes somewhere - but I personally have never changed it. *When would I expect Plots.jl to use DPI?* Ignoring font sizes: I would expect DPI to be used only if a user wanted to export a pixel-based plot image by specifying (w, h) *using physical dimensions* like inches, or centimeters. In that case, you kind of need a DPI value in order to figure out how many pixels to use. FYI: I still have an open issue trying to understand the intent of DPI in Plots.jl: #653 <#653> Once I understand what Plots.jl *intended* backends to do with the DPI value, I would probably be able to help fix the PyPlot issue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#733 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA492opgYdXY5vi9A_0SBisTqHqZeaQjks5rmGwZgaJpZM4MduM6> .

[mkborregaard]

My original post here stemmed from not understanding dpi. I understand it now. It is intended to be used with size. So, calling scatter(1:10, 1:10, size = (600, 800)) and scatter(1:10, 1:10, size = (1200, 1600), dpi = 200) will result in identical-looking plots with different dimensions. Which matters when calling savefig afterwards (but in fact has nothing to do with inches). I see the sense of this behaviour, so I think of my original post as uninformed (though maybe it could be considered to implement this behaviour for the other backends as well, if it's desired).
@ma-laforge does this make sense to you too?

[ma-laforge]

@tbreloff: I generally prefer that pixel is the base unit because my output is generally to the screen. Neither is inherently wrong, but correctly converting between units is a good thing to get right.

Agreed. Nether is inherently wrong, but I found it practical/easy to use pixels for that exact reason:

• Using "pixel" as a base unit maps well to the screen (and pixel-based images).
• If we export to vector images, like svg, we don't get any surprises either. Though there is not really such a thing as a pixel with vector images, the result looks like we expect.

When I started using Cairo, I noticed the base transform mapped directly to pixels... and found it much easier to work this way than what I did in the past (which was to draw everything in millimeters - a physical quantity).

Though working in millimeters is fine in theory, it is just annoying to get plots looking good/being readable on the screen. You basically have to figure out how many millimeters gives you a x-pixel line width.

My vote
I vote for image size, trace widths, and "symbol" sizes to be in pixels. I am still on the fence about font sizes, though.

We are indeed used to font sizes in "points" (a physical quantity), but that's not really meaningful on a plot unless we specify the plot size using physical quantities as well (ex: inches) or assigning a DPI value.

[ma-laforge]

@mkborregaard: [...] dpi [...] is intended to be used with size

Yes, the two are typically used together in order to control image size/resolution.

@mkborregaard: So, calling scatter(1:10, 1:10, size = (600, 800)) and scatter(1:10, 1:10, size = (1200, 1600), dpi = 200) will result in identical-looking plots with different dimensions. Which matters when calling savefig afterwards (but in fact has nothing to do with inches).

That is indeed what I would expect if the default resolution was set to dpi = 100. But that's not what I see at the moment with the pyplot backend.

The main (but slight) correction I would make to your statement is that the differences would not only matter when you call savefig: The second solution should also display as 2x larger on the screen, and have 2x wider lines, etc.
... but I get what you mean: They would both like exact scaled copies of each other (less enhancements you get from anti-aliasing).

@mkborregaard: (but in fact has nothing to do with inches)

To a first order, I would agree. But I think many image formats have a metadata tag that tells programs how big the image is supposed to be drawn - in some physical unit like inches, or millimeters, or something. This does not really change the quality - or overall look - of the image, though. It simply tells the end user application how big to draw things (mostly useful when you intend to print the image in the real world).

@mkborregaard: though maybe it could be considered to implement this behaviour for the other backends as well, if it's desired

Indeed, that's why I opened issue #653.

...But then again, it is not that critical of a feature: The user of Plots.jl can basically get the same effect by doubling the size = (xsize, ysize) value and doubling the line withs, symbol withs (, etc) everywhere else in their code.

[mkborregaard]

That is indeed what I would expect if the default resolution was set to dpi = 100. But that's not what I see at the moment with the pyplot backend.

Yes, something is off with the dpi scaling - it exaggerates the size of all elements too much, so e.g. setting dpi = 120 gives a similar image when quadrupling(!) the pixel number. Definetely a (minor) bug.
Worth looking into this code:

Plots.jl/src/backends/pyplot.jl

Lines 379 to 381 in 2317b77

	function py_dpi_scale(plt::Plot{PyPlotBackend}, ptsz)
	ptsz * plt[:dpi] / DPI
	end

[ma-laforge]

I personally have never quite understood when that py_dpi_scale function should have been used. It currently appears to be scaling all dimensions sent to pyplot.

This is kind of odd to me, because the :dpi setting is already sent to matplotlib in the _show function:
https://github.com/JuliaPlots/Plots.jl/blob/master/src/backends/pyplot.jl#L1251-L1262

[mkborregaard]

I think that is only for savefig. It is passed to the application window here I think https://github.com/JuliaPlots/Plots.jl/blob/master/src/backends/pyplot.jl#L990
Anyway, I almost think the only way for this to progress is if someone sits down and investigates the behavior on matplotlib and then makes a PR for the dpi behaviour that is either consistent with that or has a good internal Plots logic :-)

[ma-laforge]

Note that there is a quadratic relationship to control the marker sizes as well. I guess means someone in the call chain decided that markersize was a measure of area instead of height or width.

Plots.jl/src/backends/pyplot.jl

Line 599 in 2317b77

s = py_dpi_scale(plt, cycle(series[:markersize],i) .^ 2),

Maybe that is the way to go, but I find most people find it easier to think linearly than in terms of quadratics.

[mkborregaard]

I think it is the other way around - markersize in Plots is proportional to the diameter of the marker. This is (unfortunately) common behaviour for plotting packages. When used in a plot to designate a quantity, that quantity should be proportional to the area of the marker - so I always set ms using sqrt(my_variable).

Not sure about the relationship with DPI.

[ma-laforge]

Anyway, I almost think the only way for this to progress is if someone sits down and investigates the behavior on matplotlib and then makes a PR for the dpi behaviour that is either consistent with that or has a good internal Plots logic :-)

That sounds reasonable to me. Do we have a "reference" backend that we can use for this?

By this, I mean is there a backend that the Plots.jl group put in alot of attention to get the dimensions & scaling working the way? If so, other backends should be using this as a reference to calibrate their marker sizes, line widths, etc. ...And yes, also to get the DPI setting to behave the same as well.

I say this, because it is my understanding that the (possibly loosely defined) goal of Plots.jl is to provide backend-agnositc plot facilities. In other words, we should get more-or-less the same results, irrespective of which backend the user selects.

Is GR the reference at the moment? It sounds like GR is getting a bit more attention lately - given speed & active development. I know people seem to might want GLVisualize to become the reference, but it sounds like it is not at that point yet.

I used to thing PyPlot was the reference, but it sounds like it is getting alot less attention lately.

[mkborregaard]

AFAIK dpi is only implemented for pyplot at the moment.

[ma-laforge]

I think it is the other way around - markersize in Plots is proportional to the diameter of the circle. This is (unfortunately) common behaviour for plotting packages. When used in a plot to designate a quantity, that quantity should be proportional to the area of the marker - so I always set ms using sqrt(my_variable).

I don't think I understand: Do you mean there is a lack of seperation between when we use "markers" as simple data (position) markers vs when we generate plots that use "markers" as a way to convey the size of something at a given position?

[mkborregaard]

No - I mean like this https://www.bloomberg.com/graphics/2017-trump-budget/
The size of each circle equals the amount in $. To do this you'd need to do plot(x,y, ms = sqrt(expense)).

[ma-laforge]

Sounds like we are saying the same thing in different ways, so I recap.

sqrt(expense):
AFAICT: You are doing this in order for your symbol area to be proportional to expense.

You probably find this annoying a bit because matplotlib's default behaviour is for marker size to represent a value proportional to area (what you personally find intuitive) - but Plots.jl decided that :markersize represents diameter (not area).

Justification
I say this because :markersize gets squared before being passed to matplotlib (

Plots.jl/src/backends/pyplot.jl

Line 599 in 2317b77

s = py_dpi_scale(plt, cycle(series[:markersize],i) .^ 2),

).

As a result, (at least when using the pyplot backend) Plots.jl implicitly expects the user to specify a marker size that is proportional to diameter - so it has to square things up to translate to matplotlib's requirement to have marker size be proportional to area.