From waters.mike.j at gmail.com Tue Mar 3 13:32:33 2020 From: waters.mike.j at gmail.com (Michael J. Waters) Date: Tue, 3 Mar 2020 12:32:33 -0600 Subject: [Matplotlib-devel] Gasoline Rainbow: a modernized prism colormap Message-ID: <67b664a9-9fcd-24e6-20a9-70a94170925e@gmail.com> Hi All, I have developed a colormap, gasoline_rainbow, with high local contrast that is also perceptually uniform and linear luminant. It fulfills a similar role as prism but has some non-local contrast due to it's linear luminance. You can see it here: https://gitlab.com/mjwaters/gasoline-rainbow-colormap/-/tree/master Is there any interest in including this map in MPL?? I think it could fill a role missing from the default options. Cheers, -Mike From story645 at gmail.com Wed Mar 4 15:22:49 2020 From: story645 at gmail.com (Hannah) Date: Wed, 4 Mar 2020 15:22:49 -0500 Subject: [Matplotlib-devel] New PyPI Classifier: `Framework :: Matplotlib` Message-ID: The PyPA (Python Packaging Authority) just created the Framework :: Matplotlib classifier! Do you maintain a package that?s part of the Matplotlib ecosystem? Add Framework :: Matplotlib to the classifiers list on setup.py to help users find your project on PyPI (the Python Packaging Index). It also lets us know about your project when we tell folks about all the cool stuff built with Matplotlib. x-posted from https://discourse.matplotlib.org/t/framework-matplotlib-trove-classifier/20927 & comments should go to the discourse post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From story645 at gmail.com Wed Mar 4 15:23:05 2020 From: story645 at gmail.com (Hannah) Date: Wed, 4 Mar 2020 15:23:05 -0500 Subject: [Matplotlib-devel] Gasoline Rainbow: a modernized prism colormap In-Reply-To: <67b664a9-9fcd-24e6-20a9-70a94170925e@gmail.com> References: <67b664a9-9fcd-24e6-20a9-70a94170925e@gmail.com> Message-ID: Hi, This looks cool, but it might be better as either a stand alone package (add the `Famework :: Matplotlib` classifier for better discoverability) or bundled into https://github.com/holoviz/colorcet or https://github.com/pyviz/contrib_colormaps. You may also consider writing it up and submitting it to JOSS, similar to CMasher ( https://joss.theoj.org/papers/10.21105/joss.02004). Thanks, Hannah On Tue, Mar 3, 2020 at 1:32 PM Michael J. Waters wrote: > Hi All, > > I have developed a colormap, gasoline_rainbow, with high local contrast > that is also perceptually uniform and linear luminant. It fulfills a > similar role as prism but has some non-local contrast due to it's linear > luminance. > > You can see it here: > https://gitlab.com/mjwaters/gasoline-rainbow-colormap/-/tree/master > > Is there any interest in including this map in MPL? I think it could > fill a role missing from the default options. > > Cheers, > > -Mike > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From waters.mike.j at gmail.com Wed Mar 4 16:03:48 2020 From: waters.mike.j at gmail.com (Michael J. Waters) Date: Wed, 4 Mar 2020 15:03:48 -0600 Subject: [Matplotlib-devel] Gasoline Rainbow: a modernized prism colormap In-Reply-To: References: <67b664a9-9fcd-24e6-20a9-70a94170925e@gmail.com> Message-ID: <4d28a8ff-f55b-594a-cef4-d14d1d2981eb@gmail.com> Hi Greg, I think having monotonic luminance is good because the viewer still gets information on the overall position in the data set, not just local contrast (like with prism).? If there is sufficient interest, I could try constructing a new version that forgoes linear luminance for monotonic luminance but still is perceptually uniform. -Mike On 3/4/20 2:25 PM, Isaac Gerg wrote: > I think its?a good colormap for exploratory analysis.? I would include > it in the baseline. > > Lots of people bag on jet or rainbow but for exploratory analysis > where you have data of a large dynamic range, linear luminance is not > something you want.? I think this would be a good substitute. > > On Tue, Mar 3, 2020 at 1:32 PM Michael J. Waters > > wrote: > > Hi All, > > I have developed a colormap, gasoline_rainbow, with high local > contrast > that is also perceptually uniform and linear luminant. It fulfills a > similar role as prism but has some non-local contrast due to it's > linear > luminance. > > You can see it here: > https://gitlab.com/mjwaters/gasoline-rainbow-colormap/-/tree/master > > Is there any interest in including this map in MPL?? I think it could > fill a role missing from the default options. > > Cheers, > > -Mike > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddrjen at gmail.com Wed Mar 4 22:03:29 2020 From: toddrjen at gmail.com (Todd) Date: Wed, 4 Mar 2020 22:03:29 -0500 Subject: [Matplotlib-devel] Easier tick formatters Message-ID: Currently setting up the tick formatting on matplotlib requires you to import a formatter from the ticker module, create an instance of that formatter, then pass that to the axis. This makes sense for complicated formatting. However, there are some obvious cases where we can probably infer the type of formatting someone wants to do if we are just given the formatter content. For example * '' is probably going to be the null formatter * A callable, besides a formatter instance, is probably going to be a function formatter * A sequence or numpy array is probably going to be an index or fixed formatter, depending on the locator * Any other string is probably going to be a format string formatter or string method formatter. So I think we could allow the `set_major_formatter` and `set_minor_formatter` to take certain sorts of inputs and create the formatter automatically for the user, making such cases much, much easier. Specifically, I propose the following inputs be accepted: * `None` sets it to the default formatter * A callable (besides a formatter instance) is set to be a FuncFormatter * An empty string, `''`, is set to be a NullFormatter * Any other string is a StrMethodFormatter * An abc.collections.Sequence subclass or numpy ndarray subclass is an IndexFormatter, unless the axis is using a FixedLocator in which case it is a FixedLocator. We could restrict this to just lists and numpy arrays only. Any thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Wed Mar 4 22:15:11 2020 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 4 Mar 2020 22:15:11 -0500 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: Interesting, I am weakly in favor of this. I am normally very hesitant about adopting heuristics, but these seem well defined. If we do this, we should drop the last rule as IndexFormatter is scheduled to be deprecated in in 3.3 and is a bit problematic in other ways. I don't see any back-compatibility concerns (as none of those inputs work now). Tom On Wed, Mar 4, 2020 at 10:03 PM Todd wrote: > Currently setting up the tick formatting on matplotlib requires you to > import a formatter from the ticker module, create an instance of that > formatter, then pass that to the axis. This makes sense for complicated > formatting. However, there are some obvious cases where we can probably > infer the type of formatting someone wants to do if we are just given the > formatter content. For example > > * '' is probably going to be the null formatter > * A callable, besides a formatter instance, is probably going to be a > function formatter > * A sequence or numpy array is probably going to be an index or fixed > formatter, depending on the locator > * Any other string is probably going to be a format string formatter or > string method formatter. > > So I think we could allow the `set_major_formatter` and `set_minor_formatter` > to take certain sorts of inputs and create the formatter automatically for > the user, making such cases much, much easier. Specifically, I propose the > following inputs be accepted: > > * `None` sets it to the default formatter > * A callable (besides a formatter instance) is set to be a FuncFormatter > * An empty string, `''`, is set to be a NullFormatter > * Any other string is a StrMethodFormatter > * An abc.collections.Sequence subclass or numpy ndarray subclass is an > IndexFormatter, unless the axis is using a FixedLocator in which case it is > a FixedLocator. We could restrict this to just lists and numpy arrays only. > > Any thoughts? > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Wed Mar 4 22:57:19 2020 From: efiring at hawaii.edu (Eric Firing) Date: Wed, 4 Mar 2020 17:57:19 -1000 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: I'm very sympathetic to the goal of making smoother and simpler interfaces, but I'm not yet convinced that this proposal is the way to go. An example of a case long ago where a proposal something like this made a big improvement is the specification of a cmap kwarg: originally it had to be a Colormap instance, but then it was changed to accept a string. That worked well because it was an extremely common situation, and only one change in behavior was made--it essentially yielded expected behavior right away. Using custom formatters is much less common, I presume, and the new behavior is not as simple as supplying a colormap name. Eric On 2020/03/04 5:03 PM, Todd wrote: > Currently setting up the tick formatting on matplotlib requires you to > import a formatter from the ticker module, create an instance of that > formatter, then pass that to the axis.? This makes sense for complicated > formatting.? However, there are some obvious cases where we can probably > infer the type of formatting someone wants to do if we are just given > the formatter content.? For example > > ?? * '' is probably going to be the null formatter > ?? * A callable, besides a formatter instance, is probably going to be > a function formatter > ?? * A sequence or numpy array is probably going to be an index or > fixed formatter, depending on the locator > ?? * Any other string is probably going to be a format string formatter > or string method formatter. > > So I think we could allow the `set_major_formatter` and > `set_minor_formatter` to take certain sorts of inputs and create the > formatter automatically for the user, making such cases much, much > easier.? Specifically, I propose the following inputs be accepted: > > ?? * `None` sets it to the default formatter > ?? * A callable (besides a formatter instance) is set to be a FuncFormatter > ?? * An empty string, `''`, is set to be a NullFormatter > ?? * Any other string is a StrMethodFormatter > ?? * An abc.collections.Sequence subclass or numpy ndarray subclass is > an IndexFormatter, unless the axis is using a FixedLocator in which case > it is a FixedLocator.? We could restrict this to just lists and numpy > arrays only. > > Any thoughts? > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From waters.mike.j at gmail.com Wed Mar 4 23:24:20 2020 From: waters.mike.j at gmail.com (Michael J. Waters) Date: Wed, 4 Mar 2020 22:24:20 -0600 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: <29ee3f19-3e57-f112-95a7-034e6aba16e0@gmail.com> As a frequent user of MultipleLocator, I'd suggest that `set_major_formatter` should also accept a float if this API change is made. -Mike On 3/4/20 9:57 PM, Eric Firing wrote: > I'm very sympathetic to the goal of making smoother and simpler > interfaces, but I'm not yet convinced that this proposal is the way to > go.? An example of a case long ago where a proposal something like > this made a big improvement is the specification of a cmap kwarg: > originally it had to be a Colormap instance, but then it was changed > to accept a string.? That worked well because it was an extremely > common situation, and only one change in behavior was made--it > essentially yielded expected behavior right away. > > Using custom formatters is much less common, I presume, and the new > behavior is not as simple as supplying a colormap name. > > Eric > > On 2020/03/04 5:03 PM, Todd wrote: >> Currently setting up the tick formatting on matplotlib requires you >> to import a formatter from the ticker module, create an instance of >> that formatter, then pass that to the axis.? This makes sense for >> complicated formatting. However, there are some obvious cases where >> we can probably infer the type of formatting someone wants to do if >> we are just given the formatter content.? For example >> >> ??? * '' is probably going to be the null formatter >> ??? * A callable, besides a formatter instance, is probably going to >> be a function formatter >> ??? * A sequence or numpy array is probably going to be an index or >> fixed formatter, depending on the locator >> ??? * Any other string is probably going to be a format string >> formatter or string method formatter. >> >> So I think we could allow the `set_major_formatter` and >> `set_minor_formatter` to take certain sorts of inputs and create the >> formatter automatically for the user, making such cases much, much >> easier.? Specifically, I propose the following inputs be accepted: >> >> ??? * `None` sets it to the default formatter >> ??? * A callable (besides a formatter instance) is set to be a >> FuncFormatter >> ??? * An empty string, `''`, is set to be a NullFormatter >> ??? * Any other string is a StrMethodFormatter >> ??? * An abc.collections.Sequence subclass or numpy ndarray subclass >> is an IndexFormatter, unless the axis is using a FixedLocator in >> which case it is a FixedLocator.? We could restrict this to just >> lists and numpy arrays only. >> >> Any thoughts? >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel From antony.lee at institutoptique.fr Thu Mar 5 05:37:13 2020 From: antony.lee at institutoptique.fr (Antony Lee) Date: Thu, 5 Mar 2020 11:37:13 +0100 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: I am sympathetic to the idea. A much simpler rule, though, would be to *just* additionally accept callables. New-style format string formatters can then be implemented by passing bound methods (`set_major_formatter("tick {}".format)` -- the bound method quietly ignores the second (index) argument), which also makes it explicit that we talking about {}-format, not %s-format. Even `set_major_formatter("".format)` would already be much shorter to type than importing NullFormatter and using it. In any case, we could always first implement support for callables, which already buys us all these cases, and defer further cases to later. The only case not covered by callables/bound methods is FixedLocator, but this is already handled by set_x/yticks, and anyways (usually) involves setting both the locator and the formatter at once (and in fact is semantically more associated with setting the locator rather than the formatter), so I think it's fine to keep it separate for now. Antony On Thu, Mar 5, 2020 at 4:03 AM Todd wrote: > Currently setting up the tick formatting on matplotlib requires you to > import a formatter from the ticker module, create an instance of that > formatter, then pass that to the axis. This makes sense for complicated > formatting. However, there are some obvious cases where we can probably > infer the type of formatting someone wants to do if we are just given the > formatter content. For example > > * '' is probably going to be the null formatter > * A callable, besides a formatter instance, is probably going to be a > function formatter > * A sequence or numpy array is probably going to be an index or fixed > formatter, depending on the locator > * Any other string is probably going to be a format string formatter or > string method formatter. > > So I think we could allow the `set_major_formatter` and `set_minor_formatter` > to take certain sorts of inputs and create the formatter automatically for > the user, making such cases much, much easier. Specifically, I propose the > following inputs be accepted: > > * `None` sets it to the default formatter > * A callable (besides a formatter instance) is set to be a FuncFormatter > * An empty string, `''`, is set to be a NullFormatter > * Any other string is a StrMethodFormatter > * An abc.collections.Sequence subclass or numpy ndarray subclass is an > IndexFormatter, unless the axis is using a FixedLocator in which case it is > a FixedLocator. We could restrict this to just lists and numpy arrays only. > > Any thoughts? > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddrjen at gmail.com Thu Mar 5 09:50:44 2020 From: toddrjen at gmail.com (Todd) Date: Thu, 5 Mar 2020 09:50:44 -0500 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: On Wed, Mar 4, 2020 at 11:02 PM Eric Firing wrote: > I'm very sympathetic to the goal of making smoother and simpler > interfaces, but I'm not yet convinced that this proposal is the way to > go. An example of a case long ago where a proposal something like this > made a big improvement is the specification of a cmap kwarg: originally > it had to be a Colormap instance, but then it was changed to accept a > string. That worked well because it was an extremely common situation, > and only one change in behavior was made--it essentially yielded > expected behavior right away. > > Using custom formatters is much less common, I presume, and the new > behavior is not as simple as supplying a colormap name. > > Eric > First, I think this is a bit of a chicken and egg problem. Doing this isn't that common because it requires you jump through more hoops than most plot customization does. I don't have any hard evidence, but I would think something like adding degrees symbols to polar plots or units to any sort of plot would be a natural thing to do if it was easy. I know I personally have held off on doing it for throw-away plots because the amount of boilerplate needed. Second, there are other places in matplotlib where simpler inputs are allowed in place of more complicated ones where the inputs are relatively unambiguous. For example Axes.legend doesn't require that you manually specify which objects you are assigning labels to, you can just provide a sequence of strings. Similarly Axes.set_position can either accept a sequence of floats for a position or a Bbox. And there are lots of places you can either provide a dict of properties instead of a more complicated property object, or set_ functions where you can provide a string label and matplotlib will handle the underlying text object for you, even when the corresponding get_ function returns a text object. I don't think the expected behavior is very ambiguous here, and the implementation is very easy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddrjen at gmail.com Thu Mar 5 09:54:45 2020 From: toddrjen at gmail.com (Todd) Date: Thu, 5 Mar 2020 09:54:45 -0500 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: On Thu, Mar 5, 2020 at 5:37 AM Antony Lee wrote: > I am sympathetic to the idea. A much simpler rule, though, would be to > *just* additionally accept callables. New-style format string formatters > can then be implemented by passing bound methods > (`set_major_formatter("tick {}".format)` -- the bound method quietly > ignores the second (index) argument), which also makes it explicit that we > talking about {}-format, not %s-format. Even > `set_major_formatter("".format)` would already be much shorter to type than > importing NullFormatter and using it. In any case, we could always first > implement support for callables, which already buys us all these cases, and > defer further cases to later. > The only case not covered by callables/bound methods is FixedLocator, but > this is already handled by set_x/yticks, and anyways (usually) involves > setting both the locator and the formatter at once (and in fact is > semantically more associated with setting the locator rather than the > formatter), so I think it's fine to keep it separate for now. > Antony > > I thought of that approach, but it seemed like it still requires some unnecessary boilerplate for what seemed to me to by fairly unambiguous situations. And it also doesn't handle resetting the formatter to the default. -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddrjen at gmail.com Thu Mar 5 09:57:07 2020 From: toddrjen at gmail.com (Todd) Date: Thu, 5 Mar 2020 09:57:07 -0500 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: Okay, so then it would be `None` to reset, `''` for `NullFormatter`, a callable for `FuncFormatter`, and a string for `StrMethodFormatter`. That avoids the complexity of determining what exactly constitutes a "sequence" for the purposes of IndexFormatter/FixedFormatter. On Wed, Mar 4, 2020 at 10:15 PM Thomas Caswell wrote: > Interesting, I am weakly in favor of this. > > I am normally very hesitant about adopting heuristics, but these seem well > defined. If we do this, we should drop the last rule as IndexFormatter is > scheduled to be deprecated in in 3.3 and is a bit problematic in other ways. > > I don't see any back-compatibility concerns (as none of those inputs work > now). > > Tom > > On Wed, Mar 4, 2020 at 10:03 PM Todd wrote: > >> Currently setting up the tick formatting on matplotlib requires you to >> import a formatter from the ticker module, create an instance of that >> formatter, then pass that to the axis. This makes sense for complicated >> formatting. However, there are some obvious cases where we can probably >> infer the type of formatting someone wants to do if we are just given the >> formatter content. For example >> >> * '' is probably going to be the null formatter >> * A callable, besides a formatter instance, is probably going to be a >> function formatter >> * A sequence or numpy array is probably going to be an index or fixed >> formatter, depending on the locator >> * Any other string is probably going to be a format string formatter >> or string method formatter. >> >> So I think we could allow the `set_major_formatter` and `set_minor_formatter` >> to take certain sorts of inputs and create the formatter automatically for >> the user, making such cases much, much easier. Specifically, I propose the >> following inputs be accepted: >> >> * `None` sets it to the default formatter >> * A callable (besides a formatter instance) is set to be a >> FuncFormatter >> * An empty string, `''`, is set to be a NullFormatter >> * Any other string is a StrMethodFormatter >> * An abc.collections.Sequence subclass or numpy ndarray subclass is an >> IndexFormatter, unless the axis is using a FixedLocator in which case it is >> a FixedLocator. We could restrict this to just lists and numpy arrays only. >> >> Any thoughts? >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > > -- > Thomas Caswell > tcaswell at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony.lee at institutoptique.fr Thu Mar 5 10:32:41 2020 From: antony.lee at institutoptique.fr (Antony Lee) Date: Thu, 5 Mar 2020 16:32:41 +0100 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: The point is that if we support callables, we'll already have all these cases supported, and while appending `.format` to your string *could* be considered boilerplate, it's already considerably shorter than `FuncFormatter` (or any of the others) + the import. Finally this still doesn't preclude adding the other cases later. Supporting None as default seems likely to confuse people who'd think it means NullFormatter... Antony On Thu, Mar 5, 2020 at 3:55 PM Todd wrote: > On Thu, Mar 5, 2020 at 5:37 AM Antony Lee > wrote: > >> I am sympathetic to the idea. A much simpler rule, though, would be to >> *just* additionally accept callables. New-style format string formatters >> can then be implemented by passing bound methods >> (`set_major_formatter("tick {}".format)` -- the bound method quietly >> ignores the second (index) argument), which also makes it explicit that we >> talking about {}-format, not %s-format. Even >> `set_major_formatter("".format)` would already be much shorter to type than >> importing NullFormatter and using it. In any case, we could always first >> implement support for callables, which already buys us all these cases, and >> defer further cases to later. >> The only case not covered by callables/bound methods is FixedLocator, but >> this is already handled by set_x/yticks, and anyways (usually) involves >> setting both the locator and the formatter at once (and in fact is >> semantically more associated with setting the locator rather than the >> formatter), so I think it's fine to keep it separate for now. >> Antony >> >> > I thought of that approach, but it seemed like it still requires some > unnecessary boilerplate for what seemed to me to by fairly unambiguous > situations. And it also doesn't handle resetting the formatter to the > default. > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From waters.mike.j at gmail.com Thu Mar 5 23:48:49 2020 From: waters.mike.j at gmail.com (Michael Waters) Date: Thu, 5 Mar 2020 22:48:49 -0600 Subject: [Matplotlib-devel] Gasoline Rainbow: a modernized prism colormap In-Reply-To: References: <67b664a9-9fcd-24e6-20a9-70a94170925e@gmail.com> <4d28a8ff-f55b-594a-cef4-d14d1d2981eb@gmail.com> Message-ID: Hi all, I don't know if anyone other than Isaac Gerg is interested, but gasoline_rainbow has about 5.3x the total contrast of viridis. I understand there are some aesthetic issues with the colormap, but as an upgrade for prism, I don't think it's too bad. Cheers, -Mike On 3/4/20 3:12 PM, Isaac Gerg wrote: > sorry, I didnt?mean monotonic luminance but repeating colors. I think > the colormap is useful as it stands. > > Isaac > > On Wed, Mar 4, 2020 at 4:03 PM Michael J. Waters > > wrote: > > Hi Greg, > > I think having monotonic luminance is good because the viewer > still gets information on the overall position in the data set, > not just local contrast (like with prism).? If there is sufficient > interest, I could try constructing a new version that forgoes > linear luminance for monotonic luminance but still is perceptually > uniform. > > -Mike > > > On 3/4/20 2:25 PM, Isaac Gerg wrote: >> I think its?a good colormap for exploratory analysis.? I would >> include it in the baseline. >> >> Lots of people bag on jet or rainbow but for exploratory analysis >> where you have data of a large dynamic range, linear luminance is >> not something you want.? I think this would be a good substitute. >> >> On Tue, Mar 3, 2020 at 1:32 PM Michael J. Waters >> > wrote: >> >> Hi All, >> >> I have developed a colormap, gasoline_rainbow, with high >> local contrast >> that is also perceptually uniform and linear luminant. It >> fulfills a >> similar role as prism but has some non-local contrast due to >> it's linear >> luminance. >> >> You can see it here: >> https://gitlab.com/mjwaters/gasoline-rainbow-colormap/-/tree/master >> >> Is there any interest in including this map in MPL?? I think >> it could >> fill a role missing from the default options. >> >> Cheers, >> >> -Mike >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Fri Mar 6 08:58:08 2020 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 6 Mar 2020 08:58:08 -0500 Subject: [Matplotlib-devel] Gasoline Rainbow: a modernized prism colormap In-Reply-To: References: <67b664a9-9fcd-24e6-20a9-70a94170925e@gmail.com> <4d28a8ff-f55b-594a-cef4-d14d1d2981eb@gmail.com> Message-ID: I agree with Hannah, the proposed color map is interesting, but I think it would be better as it's own stand alone package or folded into one of {colorcet, contrib_colormaps, cmasher}. Tom On Thu, Mar 5, 2020 at 11:49 PM Michael Waters wrote: > Hi all, > > I don't know if anyone other than Isaac Gerg is interested, but > gasoline_rainbow has about 5.3x the total contrast of viridis. I understand > there are some aesthetic issues with the colormap, but as an upgrade for > prism, I don't think it's too bad. > > Cheers, > > -Mike > On 3/4/20 3:12 PM, Isaac Gerg wrote: > > sorry, I didnt mean monotonic luminance but repeating colors. I think the > colormap is useful as it stands. > > Isaac > > On Wed, Mar 4, 2020 at 4:03 PM Michael J. Waters > wrote: > >> Hi Greg, >> >> I think having monotonic luminance is good because the viewer still gets >> information on the overall position in the data set, not just local >> contrast (like with prism). If there is sufficient interest, I could try >> constructing a new version that forgoes linear luminance for monotonic >> luminance but still is perceptually uniform. >> >> -Mike >> >> >> On 3/4/20 2:25 PM, Isaac Gerg wrote: >> >> I think its a good colormap for exploratory analysis. I would include it >> in the baseline. >> >> Lots of people bag on jet or rainbow but for exploratory analysis where >> you have data of a large dynamic range, linear luminance is not something >> you want. I think this would be a good substitute. >> >> On Tue, Mar 3, 2020 at 1:32 PM Michael J. Waters >> wrote: >> >>> Hi All, >>> >>> I have developed a colormap, gasoline_rainbow, with high local contrast >>> that is also perceptually uniform and linear luminant. It fulfills a >>> similar role as prism but has some non-local contrast due to it's linear >>> luminance. >>> >>> You can see it here: >>> https://gitlab.com/mjwaters/gasoline-rainbow-colormap/-/tree/master >>> >>> Is there any interest in including this map in MPL? I think it could >>> fill a role missing from the default options. >>> >>> Cheers, >>> >>> -Mike >>> >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddrjen at gmail.com Mon Mar 9 10:45:32 2020 From: toddrjen at gmail.com (Todd) Date: Mon, 9 Mar 2020 10:45:32 -0400 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: On Wed, Mar 4, 2020 at 10:03 PM Todd wrote: > Currently setting up the tick formatting on matplotlib requires you to > import a formatter from the ticker module, create an instance of that > formatter, then pass that to the axis. This makes sense for complicated > formatting. However, there are some obvious cases where we can probably > infer the type of formatting someone wants to do if we are just given the > formatter content. For example > > * '' is probably going to be the null formatter > * A callable, besides a formatter instance, is probably going to be a > function formatter > * A sequence or numpy array is probably going to be an index or fixed > formatter, depending on the locator > * Any other string is probably going to be a format string formatter or > string method formatter. > > So I think we could allow the `set_major_formatter` and `set_minor_formatter` > to take certain sorts of inputs and create the formatter automatically for > the user, making such cases much, much easier. Specifically, I propose the > following inputs be accepted: > > * `None` sets it to the default formatter > * A callable (besides a formatter instance) is set to be a FuncFormatter > * An empty string, `''`, is set to be a NullFormatter > * Any other string is a StrMethodFormatter > * An abc.collections.Sequence subclass or numpy ndarray subclass is an > IndexFormatter, unless the axis is using a FixedLocator in which case it is > a FixedLocator. We could restrict this to just lists and numpy arrays only. > > Any thoughts? > Based on the input I have gotten so far, I have made a simplified version of the approach [1]. It only handles the cases for str and function (or rather callable, but I call it a function in the documentation). These seem to handle most use-cases reasonably well. As Antony pointed out, None is potentially confusing, and as Thomas pointed out IndexFormatter is deprecated. That left only the empty NullFormatter (with an empty str), StrMethodFormatter (with any other str), and FuncFormatter (with a callable). Antony made a good case that we should keep the number of approaches as small as possible. Since the NullFormatter is trivially handled with an empty str, and that is really what it is behind-the-scenes, that was an obvious one to cut. Antony made the good case that any str could be handled with str.format. I tried that approach initially, but the issue I ended up having is that, although it is obvious to experienced Python users, it isn't as obvious to newer users. That would mean I would need to properly communicate this workaround to users in the documentation. However, my attempts to do this ended up being longer, more complicated, and harder to understand than simply implementing the str case directly. So I ended up keeping the str and function approaches. Of course this decision is open to discussion. I also updated the documentation, tests, and examples to explain these new features. Please take a look and let me know what you think. One open issue is that I did not change any examples currently using any of these formatters, I only added the new approach. I think it might be good to change some of the simpler examples of using formatters to use this new feature in order to make formatters seem more approachable, but I haven't done that yet. [1] https://github.com/toddrjen/matplotlib/commit/673e4b32bb8849d1de7f1180d5a48b13d68a6f34 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Mar 9 14:16:25 2020 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 9 Mar 2020 14:16:25 -0400 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: It looks like something funny is going on with your branch (It looks like there are some extra rebased commits), but other than that it look like a good start. Could you please open a PR so it can go through the normal code review process / have CI run? Tom On Mon, Mar 9, 2020 at 10:45 AM Todd wrote: > On Wed, Mar 4, 2020 at 10:03 PM Todd wrote: > >> Currently setting up the tick formatting on matplotlib requires you to >> import a formatter from the ticker module, create an instance of that >> formatter, then pass that to the axis. This makes sense for complicated >> formatting. However, there are some obvious cases where we can probably >> infer the type of formatting someone wants to do if we are just given the >> formatter content. For example >> >> * '' is probably going to be the null formatter >> * A callable, besides a formatter instance, is probably going to be a >> function formatter >> * A sequence or numpy array is probably going to be an index or fixed >> formatter, depending on the locator >> * Any other string is probably going to be a format string formatter >> or string method formatter. >> >> So I think we could allow the `set_major_formatter` and `set_minor_formatter` >> to take certain sorts of inputs and create the formatter automatically for >> the user, making such cases much, much easier. Specifically, I propose the >> following inputs be accepted: >> >> * `None` sets it to the default formatter >> * A callable (besides a formatter instance) is set to be a >> FuncFormatter >> * An empty string, `''`, is set to be a NullFormatter >> * Any other string is a StrMethodFormatter >> * An abc.collections.Sequence subclass or numpy ndarray subclass is an >> IndexFormatter, unless the axis is using a FixedLocator in which case it is >> a FixedLocator. We could restrict this to just lists and numpy arrays only. >> >> Any thoughts? >> > > Based on the input I have gotten so far, I have made a simplified version > of the approach [1]. It only handles the cases for str and function (or > rather callable, but I call it a function in the documentation). These > seem to handle most use-cases reasonably well. As Antony pointed out, None > is potentially confusing, and as Thomas pointed out IndexFormatter is > deprecated. That left only the empty NullFormatter (with an empty str), > StrMethodFormatter (with any other str), and FuncFormatter (with a > callable). > > Antony made a good case that we should keep the number of approaches as > small as possible. Since the NullFormatter is trivially handled with an > empty str, and that is really what it is behind-the-scenes, that was an > obvious one to cut. > > Antony made the good case that any str could be handled with str.format. > I tried that approach initially, but the issue I ended up having is that, > although it is obvious to experienced Python users, it isn't as obvious to > newer users. That would mean I would need to properly communicate this > workaround to users in the documentation. However, my attempts to do this > ended up being longer, more complicated, and harder to understand than > simply implementing the str case directly. So I ended up keeping the str > and function approaches. Of course this decision is open to discussion. > > I also updated the documentation, tests, and examples to explain these new > features. Please take a look and let me know what you think. > > One open issue is that I did not change any examples currently using any > of these formatters, I only added the new approach. I think it might be > good to change some of the simpler examples of using formatters to use this > new feature in order to make formatters seem more approachable, but I > haven't done that yet. > > [1] > https://github.com/toddrjen/matplotlib/commit/673e4b32bb8849d1de7f1180d5a48b13d68a6f34 > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddrjen at gmail.com Mon Mar 9 20:28:25 2020 From: toddrjen at gmail.com (Todd) Date: Mon, 9 Mar 2020 20:28:25 -0400 Subject: [Matplotlib-devel] Easier tick formatters In-Reply-To: References: Message-ID: The PR is number 16715 [1] https://github.com/matplotlib/matplotlib/pull/16715 On Mon, Mar 9, 2020 at 2:16 PM Thomas Caswell wrote: > It looks like something funny is going on with your branch (It looks like > there are some extra rebased commits), but other than that it look like a > good start. > > Could you please open a PR so it can go through the normal code review > process / have CI run? > > Tom > > On Mon, Mar 9, 2020 at 10:45 AM Todd wrote: > >> On Wed, Mar 4, 2020 at 10:03 PM Todd wrote: >> >>> Currently setting up the tick formatting on matplotlib requires you to >>> import a formatter from the ticker module, create an instance of that >>> formatter, then pass that to the axis. This makes sense for complicated >>> formatting. However, there are some obvious cases where we can probably >>> infer the type of formatting someone wants to do if we are just given the >>> formatter content. For example >>> >>> * '' is probably going to be the null formatter >>> * A callable, besides a formatter instance, is probably going to be a >>> function formatter >>> * A sequence or numpy array is probably going to be an index or fixed >>> formatter, depending on the locator >>> * Any other string is probably going to be a format string formatter >>> or string method formatter. >>> >>> So I think we could allow the `set_major_formatter` and `set_minor_formatter` >>> to take certain sorts of inputs and create the formatter automatically for >>> the user, making such cases much, much easier. Specifically, I propose the >>> following inputs be accepted: >>> >>> * `None` sets it to the default formatter >>> * A callable (besides a formatter instance) is set to be a >>> FuncFormatter >>> * An empty string, `''`, is set to be a NullFormatter >>> * Any other string is a StrMethodFormatter >>> * An abc.collections.Sequence subclass or numpy ndarray subclass is >>> an IndexFormatter, unless the axis is using a FixedLocator in which case it >>> is a FixedLocator. We could restrict this to just lists and numpy arrays >>> only. >>> >>> Any thoughts? >>> >> >> Based on the input I have gotten so far, I have made a simplified version >> of the approach [1]. It only handles the cases for str and function (or >> rather callable, but I call it a function in the documentation). These >> seem to handle most use-cases reasonably well. As Antony pointed out, None >> is potentially confusing, and as Thomas pointed out IndexFormatter is >> deprecated. That left only the empty NullFormatter (with an empty str), >> StrMethodFormatter (with any other str), and FuncFormatter (with a >> callable). >> >> Antony made a good case that we should keep the number of approaches as >> small as possible. Since the NullFormatter is trivially handled with an >> empty str, and that is really what it is behind-the-scenes, that was an >> obvious one to cut. >> >> Antony made the good case that any str could be handled with str.format. >> I tried that approach initially, but the issue I ended up having is that, >> although it is obvious to experienced Python users, it isn't as obvious to >> newer users. That would mean I would need to properly communicate this >> workaround to users in the documentation. However, my attempts to do this >> ended up being longer, more complicated, and harder to understand than >> simply implementing the str case directly. So I ended up keeping the str >> and function approaches. Of course this decision is open to discussion. >> >> I also updated the documentation, tests, and examples to explain these >> new features. Please take a look and let me know what you think. >> >> One open issue is that I did not change any examples currently using any >> of these formatters, I only added the new approach. I think it might be >> good to change some of the simpler examples of using formatters to use this >> new feature in order to make formatters seem more approachable, but I >> haven't done that yet. >> >> [1] >> https://github.com/toddrjen/matplotlib/commit/673e4b32bb8849d1de7f1180d5a48b13d68a6f34 >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > > -- > Thomas Caswell > tcaswell at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quantum.analyst at gmail.com Fri Mar 20 22:24:48 2020 From: quantum.analyst at gmail.com (Elliott Sales de Andrade) Date: Fri, 20 Mar 2020 22:24:48 -0400 Subject: [Matplotlib-devel] [ANN] Matplotlib 3.2.1 release Message-ID: <134e1b5e-edc0-f99b-f48b-2cac05a6d95b@gmail.com> Hi all, I'm a bit late on this, but Matplotlib 3.2.1 was released a couple days ago. This is the first bugfix release of the 3.2.x series. This release contains several critical bug-fixes: * fix Quiver.set_UVC calls with scalar inputs * fix bezier.get_parallels failure from floating point rounding errors * fix markers specified as tuples (polygons, stars, or asterisks) * fix saving PNGs to file objects in some places * fix saving figures using the nbAgg/notebook backend * fix saving with tight layout using the PGF backend * fix setting custom datapath in rcParams (note: it is still deprecated) * fix various issues running setup.py in non-CI environments * fix xpdf distiller * various minor bug and documentation fixes PS, since there was no release announcement for 3.2.0, here are its release notes: * default image interpolation is now `'antialiased'` to better handle down-sampling and reduce artifacts when up-sampling by small ratios. * change when ticks switch to using an offset to improve readability * improvements to auto-scaling and auto-limits * `DivergingNorm` has been renamed to `TwoSlopeNorm` * support for 3 and 4 digit hex colors (`#123` maps to `#112233`) * improvements to Logit scale ticker and formatter * control of where errorbars start getting placed with `errorevery` * correct kerning when laying out text * improvements to MovieRegistry For the full details please see the whats new [1] and API changes [2] in the documentation [1] https://matplotlib.org/3.2.0/users/whats_new.html [2] https://matplotlib.org/3.2.0/api/api_changes.html PPS, for packagers, only: Since I tagged this release, and not Thomas, it is signed by my GPG key. The fingerprint is: 23CA B59E 3332 F94D 26BE F037 8D86 E7FA E5EB 0C10 and it is also used to sign this message. -- Elliott -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 870 bytes Desc: OpenPGP digital signature URL: From jklymak at uvic.ca Mon Mar 30 14:20:51 2020 From: jklymak at uvic.ca (Jody Klymak) Date: Mon, 30 Mar 2020 11:20:51 -0700 Subject: [Matplotlib-devel] Weekly meeting Message-ID: hi all Meeting agenda aNd link to zoom at https://hackmd.io/zxV2GktcRqmoy_dJIn7T6g Please add items if you?d like them discussed this week. Thanks, Jody Sent from my iPad -------------- next part -------------- An HTML attachment was scrubbed... URL: