Closed davidfokkema closed 9 years ago
Perhaps this can be an example: http://tex.stackexchange.com/a/38634
Will probably make Pillow a requirement, to generate the bitmap. Will not work for irregular bin sizes, if the bins are evenly sized between a min and max values the pixels of the bitmap will be properly scaled. So using bitmaps for the histogram should either be an option or detected by checking the bin widths.
To check if the bins are fit for graphic they should be the same size. Naively I thought this might be a good way to check:
if (len(set(x_edges[:-1] - x_edges[1:])) == 1 and
len(set(y_edges[:-1] - y_edges[1:])) == 1)
However, because bin edges are often floats chances are high that the widths they wont be perfectly identical. Perhaps we can check if they are at least equal within 1‰.
Ok, so we are not doing that. Instead make it an option and let the user take care that the bins are (approximately) linear between min and max.
Extreme example zoomed at 800%
Bitmap histogram on left, tex rectangle histogram on right
With Mac OS X - Preview - PDF - Smooth text and line art on
With Mac OS X - Preview - PDF - Smooth text and line art off
Both versions look fine when printed.
Possible solutions:
Does this happen only when you zoom in on a plot in preview? Or does preview think: wait, this is a scaled up bitmap, I'll mangle it? And the surf plot, how is that rendered? If the result is again, many squares being rendered in TeX, it does not help with speeding up large 2d histograms.
It also looks ugly if you have it at 100%, because the bitmap is also scaled up then, by Preview. This is already fixed in the pull request, larger bitmaps seem to work fine, better then the non-bitmaps used now.
As noted in #10 it would be better to improve the scaling to be depenend on the number of bins (lesser multiplier in case of more bins), instead of simply *50.
While the vector graphics version of the 2d histograms is nice, it can be very slow with large numbers of bins. Each bin is rendered as an individual square, which can easily lead to hundreds of squares being rendered. If we create a bitmap inside the axes, we could potentially save a lot of CPU time both during LaTeX build and while viewing the output.