Skip to content
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.

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

add the ability to set the transfer function label fontsize #4481

Merged
merged 10 commits into from
Sep 8, 2023

Conversation

zingale
Copy link
Member

@zingale zingale commented Jun 7, 2023

PR Summary

PR Checklist

  • New features are documented, with docstrings and narrative docs
  • Adds a test for any bugs fixed. Adds tests for new features.

@zingale zingale added enhancement Making something better viz: volume rendering labels Jun 7, 2023
matthewturk
matthewturk previously approved these changes Jun 7, 2023
Copy link
Member

@matthewturk matthewturk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it!

@zingale
Copy link
Member Author

zingale commented Jun 7, 2023

Here's the old (now default) behavior:

galaxy0030_vr_coords

and here's a render with label_fontsize=20:

galaxy0030_vr_coords_new

@zingale
Copy link
Member Author

zingale commented Jun 7, 2023

Here's the script for the above:

import yt
from yt.visualization.volume_rendering.api import Scene, create_volume_source

# Load the dataset.
ds = yt.load_sample("IsolatedGalaxy")
vol = create_volume_source(ds.all_data(), field=("gas", "density"))
sc = Scene()
sc.add_source(vol)
cam = sc.add_camera(ds, lens_type="perspective")
cam.resolution = (1920, 1280)

# You may need to adjust the alpha values to get a rendering with good contrast
# For annotate_domain, the fourth color value is alpha.


# Draw a coordinate axes triad
sc.annotate_axes(alpha=0.01, thickness=1)
sc.save_annotated(f"{ds}_vr_coords.png", sigma_clip=4)

@zingale
Copy link
Member Author

zingale commented Jun 7, 2023

pre-commit.ci autofix

@@ -364,6 +364,7 @@ def save_annotated(
self,
fname: Optional[str] = None,
label_fmt: Optional[str] = None,
label_fontsize: int = 10,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't add allowed-positional arguments to public functions in arbitrary places in the signature because it might break existing user code. Since everything here is currently allowed-positional, any new argument must be appended at the end. And because allowed-positional are a nightmare to deprecate if they ever need to be, let's make it keyword-only.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really use type hints, so I messed this up. Does this mean I should add Optional[]?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, your type hint is perfect (unless floats are also valid, in which case the annotation should reflect it). For reference, Optional[T] means "can be T or None". It's not needed here because the default value already has the proper type.

What I'm advocating for here is making new arguments keyword-only.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

Comment on lines 606 to 614
self,
resolution,
log_scale,
ax,
*,
label=None,
label_fmt=None,
label_fontsize=10,
size=10,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

label and label_fmt are currently allowed-positional, so making them suddenly keyword-only is a breaking change

Suggested change
self,
resolution,
log_scale,
ax,
*,
label=None,
label_fmt=None,
label_fontsize=10,
size=10,
self,
resolution,
log_scale,
ax,
label=None,
label_fmt=None,
*,
label_fontsize=10,
size=10,

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

@@ -369,6 +369,8 @@ def save_annotated(
sigma_clip: Optional[float] = None,
render: bool = True,
tf_rect: Optional[List[float]] = None,
*,
label_fontsize: int = 10,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

given that it ends up being passed to matplotlib.axes.Axes.tick_params, the proper type is actually Union[float, str] ('large' also works) (see https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.tick_params.html)

(Union needs to be imported as from typing import Union)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

@@ -399,6 +401,9 @@ def save_annotated(
label_fmt : str, optional
A format specifier (e.g., label_fmt="%.2g") to use in formatting
the data values that label the transfer function colorbar.
label_fontsize : int, optional
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the docstring should mention what the default value is.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... and now it should be synced with the type annotation.
It'd be worth linking to https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.tick_params.html#matplotlib.axes.Axes.tick_params
too, so users get first hand documentation for what strings mean in this context.
But maybe we could just type this as float and hide this implementation detail.

(sorry that it's taking so many iterations, I promise we'll converge after this one)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated. I didn't put the URL in, but I gave some examples. I don't see any other docstrings that embed URLs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know a couple docstring where urls to matplotlib doc would be very useful, but here it's not crucial. Thanks !

@zingale
Copy link
Member Author

zingale commented Jun 8, 2023

pre-commit.ci autofix

@@ -686,7 +694,7 @@ def y_format(y, pos):
ax.set_xlim(0.0, max_alpha)
ax.get_xaxis().set_ticks([])
ax.set_ylim(visible[0].item(), visible[-1].item())
ax.tick_params(axis="y", colors="white", size=10)
ax.tick_params(axis="y", colors="white", labelsize=label_fontsize)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took me long enough (sorry again) but I just realised that you're exposing the tick label size, not the size of the colorbar label itself (in fact, it's already exposed as the size parameter). I think the parameter would be better named tick_label_size.

I also see now that the actual colorbar label size is automatically scaled according to the resolution, so wouldn't it make sense to do the same thing with tick labels so their size, relative to the colorbar label, would be resolution-independent ?
There's still value in exposing both parameters independently as you're doing here, so we can keep the bulk of your patch as is, but we'd need remove references to special strings from matplotlib.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all of the label parameters (this would make 3) are for the tick labels. So if you change this one, all 3 should be changed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I see. Let's keep the name then. What about auto-scaling ?

@matthewturk
Copy link
Member

I think we can probably accept the patch as-is and supply additional patches if truly necessary. This is a useful piece of functionality and I don't want us to get too strict.

@neutrinoceros
Copy link
Member

I'd be happy to make the change I'm proposing as a follow up PR if it wasn't going to break what's introduced here. I can however propose to make the patch myself within this PR

@matthewturk
Copy link
Member

I think we should try to keep the number of iterations as low as possible, which I know you also agree with -- and to that end, compromise on some things that will have minimal impact on the potential or actual end users. (It's hard because I too don't always know exactly the right end point or where things will go when I start reviewing!) I don't think we need to get into it, because I think we're probably in agreement, and I just wanted to note that I think that balance is something that in this particular case we should continue to pay attention to.

@zingale
Copy link
Member Author

zingale commented Jun 9, 2023

I'd prefer to deal with the autoscaling in a different PR. I'm indifferent to it.

@neutrinoceros
Copy link
Member

Ok, I'm willing to do the follow up PR but I might not be able to guarantee 100% stability with respect to this one doing so (I expect you won't need to use your new, still valuable, keyword argument after that). Does this sound acceptable to you ?

@zingale
Copy link
Member Author

zingale commented Jun 9, 2023

oh, I think I misunderstood you. It is important to be able to set the size of the variable name and the size of the labels (what you call ticks) independently.

@neutrinoceros
Copy link
Member

Agreed, that's why I still think your patch has value in itself. But getting legible label size by default would also help, wouldn't it ?

@matthewturk
Copy link
Member

This looks pretty good to me as is, and I'm not sure I understand the disagreement.

@neutrinoceros
Copy link
Member

I didn't mean to block this. I'm willing to start the conversation afresh.

@neutrinoceros
Copy link
Member

I apologies for how long it took me to circle back here. It's become hard for me to return to the mindset in which I wrote my last review, and I don't want to block this any longer.
Resolving the merge conflict should be sufficient to get this in.

@neutrinoceros
Copy link
Member

pre-commit.ci autofix

@neutrinoceros neutrinoceros added this to the 4.3.0 milestone Sep 8, 2023
@neutrinoceros neutrinoceros enabled auto-merge (squash) September 8, 2023 17:28
@neutrinoceros
Copy link
Member

@yt-fido test this please

1 similar comment
@neutrinoceros
Copy link
Member

@yt-fido test this please

@neutrinoceros neutrinoceros merged commit f4ff824 into yt-project:main Sep 8, 2023
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants