You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Download as png a small size chart does not show all data #42
The browser vs download difference here is really one of rounding and a peculiarity of how we have to draw bar charts. With bargap=0 (as is the default for histograms) or when you stack bars (also the case here) we need to disable antialiasing (css shape-rendering: crispEdges;) otherwise you get horrible artifacts where bars meet. But then when you draw with low resolution, some items simply disappear.
It's kind of an interesting question actually, what we should do with bar widths in this plot. We don't currently have any way to explicitly set the width of bars in a bar chart / histogram, they just get set as wide as they can with the constraints that 1) they're all the same within one trace, 2) they don't overlap each other within one trace, and 3) if barmode is 'stack' or 'group', all the traces get the same bar width.
In this plot you've explicitly set bin widths, which SHOULD be the same as the bar widths if we want to interpret histograms in the normal way. BUT because barmode='stack' all the widths have to be the same, so we have conflicting demands. What to do?
@etpinard you still want to call this a bug? I suppose could imagine a rule like "if we're going to rasterize, AND a bar (stack) has width < 1 px AND there's no bar to draw on at least one side of it, expand it to at least one px width. But that's super complicated and I still think it sounds sketchy - what if for example the plot is a comb, consisting of 0.1 px bars separated by 0.1 px? Then you have to figure out that there's a bar near (but not quite touching) and not expand so much that you overlap it... and even then you give a misleading picture, because it would look like the space is filled when really it's only half full.
The real problem here seems to me the conflicting demands on bar widths. How do we handle grouped or stacked histograms with explicitly different bin widths? I'd almost like to make that an error, but at the very least we should let the user know somehow, and harmonize them before binning, not during plotting, so we can ensure that bin width and bar width are always the same.
The thing is, those bins are the ones use by plotly by default. I didn't specified them I juste took the data directly from plotly in my example. Which is related to #50
See: https://jsbin.com/gugerelemu/1/edit?js,console,output
That's why the image output is exactly the same even when no bin size is specified.
yup, #50 is the crux - what we should really be doing here is calculating the histogram autobins taking all histogram traces into account at the same time. Then you'd probably get a bin size of 1 or 2 and this would all be moot.
From the plot.ly workspace you can download your image at arbitrary (higher) resolution, but the version on the plot itself is not so full featured.
No. This issues that @Ni-Hil pointed out are now split into #50 and #83 .
yup, #50 is the crux - what we should really be doing here is calculating the histogram autobins taking all histogram traces into account at the same time.
We would have to be careful here. Calculating histogram autobins from all traces might break some plots that maneuver around that problem.
Activity
etpinard commentedon Nov 27, 2015
Bug confirmed. Thanks very much for providing a jsbin example.
After some investigation, the bug seems to be only present in 1-data pt
histogramtraces.Possible workaround: modify all the 1-data pt histogram traces to bars with
y: [1].alexcjohnson commentedon Dec 4, 2015
The browser vs download difference here is really one of rounding and a peculiarity of how we have to draw bar charts. With
bargap=0(as is the default for histograms) or when you stack bars (also the case here) we need to disable antialiasing (cssshape-rendering: crispEdges;) otherwise you get horrible artifacts where bars meet. But then when you draw with low resolution, some items simply disappear.It's kind of an interesting question actually, what we should do with bar widths in this plot. We don't currently have any way to explicitly set the width of bars in a bar chart / histogram, they just get set as wide as they can with the constraints that 1) they're all the same within one trace, 2) they don't overlap each other within one trace, and 3) if
barmodeis'stack'or'group', all the traces get the same bar width.In this plot you've explicitly set bin widths, which SHOULD be the same as the bar widths if we want to interpret histograms in the normal way. BUT because
barmode='stack'all the widths have to be the same, so we have conflicting demands. What to do?alexcjohnson commentedon Dec 7, 2015
@etpinard you still want to call this a bug? I suppose could imagine a rule like "if we're going to rasterize, AND a bar (stack) has width < 1 px AND there's no bar to draw on at least one side of it, expand it to at least one px width. But that's super complicated and I still think it sounds sketchy - what if for example the plot is a comb, consisting of 0.1 px bars separated by 0.1 px? Then you have to figure out that there's a bar near (but not quite touching) and not expand so much that you overlap it... and even then you give a misleading picture, because it would look like the space is filled when really it's only half full.
The real problem here seems to me the conflicting demands on bar widths. How do we handle grouped or stacked histograms with explicitly different bin widths? I'd almost like to make that an error, but at the very least we should let the user know somehow, and harmonize them before binning, not during plotting, so we can ensure that bin width and bar width are always the same.
fparga commentedon Dec 7, 2015
The thing is, those bins are the ones use by plotly by default. I didn't specified them I juste took the data directly from plotly in my example. Which is related to #50
See: https://jsbin.com/gugerelemu/1/edit?js,console,output
That's why the image output is exactly the same even when no bin size is specified.
fparga commentedon Dec 7, 2015
My question might be naive, but does the downloaded image necessary needs to be the same size as the displayed plot?
alexcjohnson commentedon Dec 7, 2015
yup, #50 is the crux - what we should really be doing here is calculating the histogram autobins taking all histogram traces into account at the same time. Then you'd probably get a bin size of 1 or 2 and this would all be moot.
From the plot.ly workspace you can download your image at arbitrary (higher) resolution, but the version on the plot itself is not so full featured.
fparga commentedon Dec 7, 2015
Any chance this might change in the future? That's quite a big limitation..
etpinard commentedon Dec 7, 2015
@alexcjohnson @Ni-Hil
No. This issues that @Ni-Hil pointed out are now split into #50 and #83 .
We would have to be careful here. Calculating histogram autobins from all traces might break some plots that maneuver around that problem.
alexcjohnson commentedon Dec 7, 2015
Migrated part of this discussion to #50 and @etpinard opened #83 with another part - is there anything left here or should we close it?
fparga commentedon Dec 10, 2015
I guess there is nothing more. Fixing #50 should fix this, so I'm closing.
amirmog commentedon Oct 7, 2016
Hello folks,
I'm still encountering this issue.
I'm drawing bar charts and some of the bars are missing.
Any ideas how to fix it?
Thanks,