Skip to content

[Bug]: Rasterized Artists in DrawingArea will be misplaced in the vectorized backend #28549

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
Mr-Milk opened this issue Jul 12, 2024 · 7 comments
Open

[Bug]: Rasterized Artists in DrawingArea will be misplaced in the vectorized backend #28549

Mr-Milk opened this issue Jul 12, 2024 · 7 comments

Comments

@Mr-Milk
Copy link
Contributor

Mr-Milk commented Jul 12, 2024

Bug summary

If I rasterized artists in DrawingArea, they are rendered correctly in rasterized backend but will be misplaced in the vectorized backend

Code for reproduction

import matplotlib.pyplot as plt
from matplotlib.offsetbox import AnchoredOffsetbox, DrawingArea
from matplotlib.patches import Rectangle
from matplotlib.collections import PatchCollection

for backend in ["png", "pdf", "svg"]:
    for rasterized in [True, False]:
        fig, ax = plt.subplots(figsize=(2, 2))
        box = DrawingArea(10, 10)
        rects = PatchCollection([
            Rectangle((0, i), width=10, height=1, ec="red")
            for i in range(10)
        ])
        rects.set_rasterized(rasterized)
        box.add_artist(rects)
        canvas = AnchoredOffsetbox(child=box, loc="center", pad=0)
        ax.add_artist(canvas)
        fig.savefig(f"DA_rasterized={rasterized}.{backend}")

Actual outcome

When set rasterized=True and in backend svg or pdf:
image

In other situations, it's properly render:
image

Expected outcome

This is expected in any situation:
image

Additional information

No response

Operating system

OS/X arm

Matplotlib Version

3.9.1

Matplotlib Backend

module://matplotlib_inline.backend_inline

Python version

3.10.13

Jupyter version

4.1.1

Installation

pip
@Mr-Milk
Copy link
Contributor Author

Mr-Milk commented Jul 17, 2024

Is there any follow up on this behavior?

@timhoffm
Copy link
Member

I suspect HiDPI is messing in the positioning, but no time to investigate.

@rcomer
Copy link
Member

rcomer commented Jul 17, 2024

This feels similar to #27763. I wonder if the root cause is the same. @Mr-Milk do you know if the behaviour was correct before v3.7.2?

@Mr-Milk
Copy link
Contributor Author

Mr-Milk commented Jul 17, 2024

I tested on v3.7.1. The results are still the same.

@jklymak
Copy link
Member

jklymak commented Jul 17, 2024

Presumably DrawingArea does not deal with dpi changes properly. Someone who uses DrawingArea would need to chase down why this is broken.

@mjfield2
Copy link

mjfield2 commented Sep 19, 2024 •
edited
Loading

I am also having issues with rasterized graphics rendering in the incorrect position when saving to pdf. Notably, setting the dpi to 72 as in #10844 corrects the positioning issue. My situation does not include Drawing Area but includes rasterized artists, patches, gridspec, an inset axis, and annotations. When using a dpi other than 72 the axes, patches, and annotations appear as they should but the rasterized artists are scaled incorrectly. The higher the dpi the smaller the rasterized artists appear in the lower left hand corner. Matplotlib version 3.9.1

Edit: removing bbox_inches='tight' solves my issue

@rcomer
Copy link
Member

rcomer commented Dec 28, 2024 •
edited
Loading

It looks like DrawingArea, along with the other containers in the offsetbox module, is explicitly designed to work in display units. E.g. the offset is set in display units. Then the transform is set once according to the passed renderer. Since we have not started rasterizing at this point, the transform for pdf will use a dpi of 72. It is not clear to me that we can fix this without at least changing the offset to be in some other units, e.g. figure inches.

@mjfield2 your issue looks more similar to #27763, which is fixed ready for v3.11. If you want to check whether your case is fixed, you can install a nightly build. If it isn't please feel free to open a new issue with the details (though note we are aware of a remaining small offset with inset_axes - #29383).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@jklymak @timhoffm @rcomer @Mr-Milk @mjfield2