[matplotlib-devel] backend_macosx framework check fails with 64bit Python
Hi again, cc'ing the matplotlib list this time, for the latter: when building matplotlib against a fink-installed python compiled in 64bit mode I found the check for a framework-installed Python (rev 8365) fails, and matplotlib fails to load, because the MacOS module is not available in 64bit. Actually Apple seems to have made it still available in their system Python, but it's likely to be a general problem on 64bit OS X installations, and will be for python3 as well. I believe I have fixed the patch file issue that came from an accidental edit of the patch file (off by 1 space character). For the issues below, can you give me some examples that show the behavior that is broken now, but fixed into your updated patch? I haven't used matplotlib in a long time. thanks, the fixed patch in unstable compiles and runs now. Sorry for the late reply; I found that the issue that my extra patch addressed actually only seems to exist for x86_64 on Snow Leopard. It is in fact not directly related to python being built as a framework, but the "import MacOS" used to check for the framework version fails, since the MacOS module is not available in 64bit. Or so the python docs state, but Apple seems to have retrofitted it somehow into their system python, so my test for "import MacOS" worked with /usr/bin/python even on Snow Leopard. So the test for MacOS.WMAvailable() that my patch removed can obviously stay there for 32bit installations, and it would probably be better to just catch the import error on 64bit systems. I'll try to work something out along those lines, and probably send it upstream to the matplotlib folks as well, since this should be a general problem on 64bit systems; and also the MacOS module is going to be removed altogether in python3.x. I'll keep you posted. I've put the import inside the check now and have it print the warning in both cases (assuming Python is not a framework installation if it lacks the MacOS module). I don't know if there might be an alternative way to check for the framework property for later, and I just picked an error to raise that seemed sensible - feel free to change that as necessary. Cheers, Derek MacOS-64bit.patch Description: Binary data -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
Ah, the list config got me ... (resending to list) 2010/8/10 Benjamin Root : > I am working on a function that can take a Colormap object and return a > grayscale form of it. Ideally, I would like to return the same type of > Colormap that was provided, but I am wondering if this is necessary. I > supposed it is sufficient to just create a LinearSegmentedColormap from the > self._lut data? > > The problem I see with that approach is that there is still possibly some > information loss, particularly with the alpha part of the rgba data. > LinearSegmentedColormap has a .from_list() function, but it uses only the > rgb part of the rgba array and does not take alpha data. > > Is the inability of setting alpha a problem? Or maybe I should use > deepcopy() instead? If you mean me, I really don't know, but I think it is always better to do things properly than to publish something done with the attitute "just working" So I think it is probably best to code it into the Colormap object itself, so that each and ever derived class can define its own method of how to create a greyscale version. What do you think about that? Friedrich -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
On 08/10/2010 10:27 AM, Friedrich Romstedt wrote: > Ah, the list config got me ... (resending to list) > > 2010/8/10 Benjamin Root: >> I am working on a function that can take a Colormap object and return a >> grayscale form of it. Ideally, I would like to return the same type of >> Colormap that was provided, but I am wondering if this is necessary. I >> supposed it is sufficient to just create a LinearSegmentedColormap from the >> self._lut data? >> >> The problem I see with that approach is that there is still possibly some >> information loss, particularly with the alpha part of the rgba data. >> LinearSegmentedColormap has a .from_list() function, but it uses only the >> rgb part of the rgba array and does not take alpha data. >> >> Is the inability of setting alpha a problem? Or maybe I should use >> deepcopy() instead? > > If you mean me, I really don't know, but I think it is always better > to do things > properly than to publish something done with the attitute "just > working" > > So I think it is probably best to code it into the Colormap object > itself, so that each and ever derived class can define its own method > of how to create a greyscale version. What do you think about that? Good idea. The base class could define a default to_grayscale() method that would do the conversion near the very end of the Colormap.__call__ method if an as_gray attribute, also defined in the base class, is True. No need for getters and setters--let it be a simple attribute. This is much simpler than generating a whole new colormap--instead, just set an attribute to switch an existing colormap to gray or back to color. I would leave the switch out of the __init__ args and kwargs. If someone wants grey, they can add one more line of code to set the attribute. I suspect only a small fraction of users will need this. If people really are going to want to fiddle with the conversion function, then the scheme above could easily be extended by allowing the as_gray attribute to be a callable; if it is a callable, then to_grayscale() would use it instead of the default function. Eric > > Friedrich > -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] backend_macosx framework check fails with 64bit Python
2010/8/10 Derek Homeier : > Hi again, cc'ing the matplotlib list this time, > > for the latter: when building matplotlib against a fink-installed python > compiled in 64bit mode > I found the check for a framework-installed Python (rev 8365) fails, and > matplotlib fails to load, > because the MacOS module is not available in 64bit. Hmm, do you claim that MacOS is in general not available in x86_64? Just my 2 cents: pb-d-128-141-26-145:~ Friedrich$ python-32 Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53) [GCC 4.2.1 (Apple Inc. build 5659)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MacOS >>> ^D pb-d-128-141-26-145:~ Friedrich$ python-64 Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53) [GCC 4.2.1 (Apple Inc. build 5659)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MacOS >>> ^D This is a self-compiled python.org Python 2.6.5 residing in /Library/Frameworks/Python.framwork: ./configure --enable-framework --with-universal-archs=intel --enable-universalsdk=/ with MACOSX_DEPLOYMENT_TARGET=10.4 GCC=gcc-4.2 Please bear with me, but how does framework/not-framework interfere with the build of the MacOS module? > (assuming Python is not a framework installation if it lacks the MacOS > module). Are there more implications? I always thought framework build just means to put it in /Library/Framworks/Python.framework. Friedrich -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
On Tue, Aug 10, 2010 at 4:21 PM, Eric Firing wrote: > On 08/10/2010 10:27 AM, Friedrich Romstedt wrote: > > Ah, the list config got me ... (resending to list) > > > > 2010/8/10 Benjamin Root: > >> I am working on a function that can take a Colormap object and return a > >> grayscale form of it. Ideally, I would like to return the same type of > >> Colormap that was provided, but I am wondering if this is necessary. I > >> supposed it is sufficient to just create a LinearSegmentedColormap from > the > >> self._lut data? > >> > >> The problem I see with that approach is that there is still possibly > some > >> information loss, particularly with the alpha part of the rgba data. > >> LinearSegmentedColormap has a .from_list() function, but it uses only > the > >> rgb part of the rgba array and does not take alpha data. > >> > >> Is the inability of setting alpha a problem? Or maybe I should use > >> deepcopy() instead? > > > > If you mean me, I really don't know, but I think it is always better > > to do things > > properly than to publish something done with the attitute "just > > working" > > > > So I think it is probably best to code it into the Colormap object > > itself, so that each and ever derived class can define its own method > > of how to create a greyscale version. What do you think about that? > > Good idea. The base class could define a default to_grayscale() method > that would do the conversion near the very end of the Colormap.__call__ > method if an as_gray attribute, also defined in the base class, is True. > No need for getters and setters--let it be a simple attribute. This > is much simpler than generating a whole new colormap--instead, just set > an attribute to switch an existing colormap to gray or back to color. I > would leave the switch out of the __init__ args and kwargs. If someone > wants grey, they can add one more line of code to set the attribute. I > suspect only a small fraction of users will need this. > > If people really are going to want to fiddle with the conversion > function, then the scheme above could easily be extended by allowing the > as_gray attribute to be a callable; if it is a callable, then > to_grayscale() would use it instead of the default function. > > Eric > > > > > Friedrich > > > > Interesting ideas, I will try that out tonight. Ben Root -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
2010/8/10 Eric Firing : > On 08/10/2010 10:27 AM, Friedrich Romstedt wrote: >> So I think it is probably best to code it into the Colormap object >> itself, so that each and ever derived class can define its own method >> of how to create a greyscale version. What do you think about that? > > Good idea. The base class could define a default to_grayscale() method > that would do the conversion near the very end of the Colormap.__call__ > method if an as_gray attribute, also defined in the base class, is True. > No need for getters and setters--let it be a simple attribute. This > is much simpler than generating a whole new colormap--instead, just set > an attribute to switch an existing colormap to gray or back to color. I > would leave the switch out of the __init__ args and kwargs. > If someone > wants grey, they can add one more line of code to set the attribute. Hmm, one would have to do it for every colormap used. Also, it would be not so obvious if using the default colormap. > I > suspect only a small fraction of users will need this. I like this, it's a good idea enabling to not repeat all the stuff in the code. But hey, wouldn't it be the same to just overload the __call__ method? class GrayColorbar(RgbColorbar): """A colorbar returning grayscaled version.""" def __call__(self, value): """Transforms RgbColorbar's value into grayscale, and returns it. rgb = BaseClass.__call__(self, value) [do stuff] return grayscale Agreed, one has to this for all the classes, while your solution works generically in ColormapBase or whatever it's called. Another option would be, to wrap the Colormap into a thin layer with __call__, but this appears way too clumsy and too hacky to me. It's a clumsy way of deriving from the class. Otherwise it's maybe also nice, because it's generic, for all Colormaps. __getattr__ and __setattr__ (iirc) could be used to simulate the wrapped instance fully. Is there some layer dealing with colors in the renderers, where the conversion could also happen? I'm asking because of displaying color images etc. and printing them as grayscale. With this, we would get rid of the alpha stuff completely, too. Maybe a general matplotlib.rc switch 'greyscale' would be possible. It would leave room for tons of improvement, e.g. automatically setting the color cycle to - -- -. etc., there was some monthes ago discussion about how to achieve that. Another advantage: It's zero loc if set in the config file ;-) I think that would be a real neat new feature. I agree what's not needed is mixed greyscale and colour display in the same Figure. Bear with me if my ideas are always too radical. Friedrich -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] backend_macosx framework check fails with 64bit Python
Hi Friedrich, >> for the latter: when building matplotlib against a fink-installed python >> compiled in 64bit mode >> I found the check for a framework-installed Python (rev 8365) fails, and >> matplotlib fails to load, >> because the MacOS module is not available in 64bit. > > Hmm, do you claim that MacOS is in general not available in x86_64? I intended to, since the fink porting description for Python under OS X 10.6 states so, and I was also mislead by the statement "not available in 64-bit mode" in http://docs.python.org/library/macos.html , but the latter, I realised, applied just to individual functions (in this case, the last one in the list). You are right, in principle MacOS.WMAvailable() should still be available (;-) on x86_64. > Just my 2 cents: > > pb-d-128-141-26-145:~ Friedrich$ python-32 > Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53) > [GCC 4.2.1 (Apple Inc. build 5659)] on darwin > Type "help", "copyright", "credits" or "license" for more information. import MacOS ^D > pb-d-128-141-26-145:~ Friedrich$ python-64 > Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53) > [GCC 4.2.1 (Apple Inc. build 5659)] on darwin > Type "help", "copyright", "credits" or "license" for more information. import MacOS ^D > > This is a self-compiled python.org Python 2.6.5 residing in > /Library/Frameworks/Python.framwork: > ./configure --enable-framework --with-universal-archs=intel > --enable-universalsdk=/ > with > MACOSX_DEPLOYMENT_TARGET=10.4 > GCC=gcc-4.2 > > Please bear with me, but how does framework/not-framework interfere > with the build of the MacOS module? >> (assuming Python is not a framework installation if it lacks the MacOS >> module). > > Are there more implications? I always thought framework build just > means to put it in /Library/Framworks/Python.framework. Good question - all I can tell at this point is that in fink, python is not built as a framework, merely with ./configure --enable-shared and on Snow Leopard this fails: miranda:2843> /sw/bin/python2.6 Python 2.6.5 (r265:79063, Jul 19 2010, 02:30:51) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MacOS Traceback (most recent call last): File "", line 1, in ImportError: No module named MacOS miranda:2844> /usr/bin/python Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/Users/derek/.pythonrc", line 22, in readline.read_history_file(historyPath) IOError: [Errno 2] No such file or directory >>> import MacOS >>> MacOS.WMAvailable() True >>> ^D There is no patch that would have explicitly removed the module in the fink install, so all I can think of is that not enabling framework and/or SDK build is responsible. I did not find any hint in the Mac build documentation towards this, though. If this is a fink-related problem only, of course we'd just need to apply the patch I've created to the fink package. But matplotlib will probably have to deal with it whenever it is going to be python3-ready. Cheers, Derek -- - Derek Homeier Institut für Astrophysik Göttingen Georg-August-Universität Phone: +49 551 39-7980 Friedrich-Hund-Platz 1Fax: +49 551 39-5043 D-37077 Göttingen, GermanyFeet: E.04.104 Web: http://www.astro.physik.uni-goettingen.de/~derek/ - -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
On 08/10/2010 11:58 AM, Friedrich Romstedt wrote: > 2010/8/10 Eric Firing: >> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote: >>> So I think it is probably best to code it into the Colormap object >>> itself, so that each and ever derived class can define its own method >>> of how to create a greyscale version. What do you think about that? >> >> Good idea. The base class could define a default to_grayscale() method >> that would do the conversion near the very end of the Colormap.__call__ >> method if an as_gray attribute, also defined in the base class, is True. >> No need for getters and setters--let it be a simple attribute. This >> is much simpler than generating a whole new colormap--instead, just set >> an attribute to switch an existing colormap to gray or back to color. I >> would leave the switch out of the __init__ args and kwargs. > >> If someone >> wants grey, they can add one more line of code to set the attribute. > > Hmm, one would have to do it for every colormap used. Also, it would > be not so obvious if using the default colormap. > >> I >> suspect only a small fraction of users will need this. > > I like this, it's a good idea enabling to not repeat all the stuff in > the code. But hey, wouldn't it be the same to just overload the > __call__ method? > > class GrayColorbar(RgbColorbar): > """A colorbar returning grayscaled version.""" > > def __call__(self, value): > """Transforms RgbColorbar's value into grayscale, and returns it. > > rgb = BaseClass.__call__(self, value) > [do stuff] > return grayscale Why make a whole new class instead of switching a behavior in an existing class? > > Agreed, one has to this for all the classes, while your solution works > generically in ColormapBase or whatever it's called. I think my solution (with slight modification) is also very compatible with your suggestion below to have an rc param that switches between color and gray. If as_gray is None, use the rc value; otherwise, let it act as described above. The typical use case is when one wants color initially, but then must regenerate plots in black and white to reduce publication costs. Your rc suggestion facilitates such switching. > > Another option would be, to wrap the Colormap into a thin layer with > __call__, but this appears way too clumsy and too hacky to me. It's a > clumsy way of deriving from the class. Otherwise it's maybe also > nice, because it's generic, for all Colormaps. __getattr__ and > __setattr__ (iirc) could be used to simulate the wrapped instance > fully. I don't follow you on this--I don't understand at all. > > Is there some layer dealing with colors in the renderers, where the > conversion could also happen? I'm asking because of displaying color > images etc. and printing them as grayscale. With this, we would get > rid of the alpha stuff completely, too. I don't understand why you would want to push this down into the renderers instead of keeping it at a higher level. And I don't know what you mean by "getting rid of the alpha stuff". > > Maybe a general matplotlib.rc switch 'greyscale' would be possible. > It would leave room for tons of improvement, e.g. automatically > setting the color cycle to - -- -. etc., there was some monthes ago > discussion about how to achieve that. Another advantage: It's zero > loc if set in the config file ;-) Yes, there does seem to be a need for these sorts of switching operations. Getting back to the colormap question, our discussions have been based on the assumption that an rgb_to_gray function is all that is needed. But is this true? Or will users actually need completely different graymaps rather than something resembling a black-and-white photo of a colormap? If so, then my suggested strategy is useless. Eric > > I think that would be a real neat new feature. > > I agree what's not needed is mixed greyscale and colour display in the > same Figure. > > Bear with me if my ideas are always too radical. > > Friedrich -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
On Tue, Aug 10, 2010 at 7:20 PM, Eric Firing wrote: > On 08/10/2010 11:58 AM, Friedrich Romstedt wrote: > > 2010/8/10 Eric Firing: > >> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote: > >>> So I think it is probably best to code it into the Colormap object > >>> itself, so that each and ever derived class can define its own method > >>> of how to create a greyscale version. What do you think about that? > >> > >> Good idea. The base class could define a default to_grayscale() method > >> that would do the conversion near the very end of the Colormap.__call__ > >> method if an as_gray attribute, also defined in the base class, is True. > >> No need for getters and setters--let it be a simple attribute. This > >> is much simpler than generating a whole new colormap--instead, just set > >> an attribute to switch an existing colormap to gray or back to color. I > >> would leave the switch out of the __init__ args and kwargs. > > > >> If someone > >> wants grey, they can add one more line of code to set the attribute. > > > > Hmm, one would have to do it for every colormap used. Also, it would > > be not so obvious if using the default colormap. > > > >> I > >> suspect only a small fraction of users will need this. > > > > I like this, it's a good idea enabling to not repeat all the stuff in > > the code. But hey, wouldn't it be the same to just overload the > > __call__ method? > > > > class GrayColorbar(RgbColorbar): > > """A colorbar returning grayscaled version.""" > > > > def __call__(self, value): > > """Transforms RgbColorbar's value into grayscale, and returns > it. > > > > rgb = BaseClass.__call__(self, value) > > [do stuff] > > return grayscale > > Why make a whole new class instead of switching a behavior in an > existing class? > > > > > Agreed, one has to this for all the classes, while your solution works > > generically in ColormapBase or whatever it's called. > > I think my solution (with slight modification) is also very compatible > with your suggestion below to have an rc param that switches between > color and gray. If as_gray is None, use the rc value; otherwise, let it > act as described above. > > The typical use case is when one wants color initially, but then must > regenerate plots in black and white to reduce publication costs. Your > rc suggestion facilitates such switching. > > > > > Another option would be, to wrap the Colormap into a thin layer with > > __call__, but this appears way too clumsy and too hacky to me. It's a > > clumsy way of deriving from the class. Otherwise it's maybe also > > nice, because it's generic, for all Colormaps. __getattr__ and > > __setattr__ (iirc) could be used to simulate the wrapped instance > > fully. > > I don't follow you on this--I don't understand at all. > > > > > > Is there some layer dealing with colors in the renderers, where the > > conversion could also happen? I'm asking because of displaying color > > images etc. and printing them as grayscale. With this, we would get > > rid of the alpha stuff completely, too. > > I don't understand why you would want to push this down into the > renderers instead of keeping it at a higher level. And I don't know > what you mean by "getting rid of the alpha stuff". > > > > > Maybe a general matplotlib.rc switch 'greyscale' would be possible. > > It would leave room for tons of improvement, e.g. automatically > > setting the color cycle to - -- -. etc., there was some monthes ago > > discussion about how to achieve that. Another advantage: It's zero > > loc if set in the config file ;-) > > Yes, there does seem to be a need for these sorts of switching > operations. Getting back to the colormap question, our discussions have > been based on the assumption that an rgb_to_gray function is all that is > needed. But is this true? Or will users actually need completely > different graymaps rather than something resembling a black-and-white > photo of a colormap? If so, then my suggested strategy is useless. > > Eric > > > > > I think that would be a real neat new feature. > > > > I agree what's not needed is mixed greyscale and colour display in the > > same Figure. > > > > Bear with me if my ideas are always too radical. > > > > Friedrich > > I have to agree with Eric on this. Maybe I am just not understanding Friedrich's thought process. If someone wants a specific greyscale colormapping, then they can make it themselves just like any other colormap. However, it is as a matter of convenience and ease to say "hey, I have this colormap that I have been using in my code, but I need its greyscale equivalent". My idea is this. It appears that all colormappings get a lookup table (self._lut) that contains rgba values. We could also simultaneously maintain a second lookup table (initialized only when needed). Therefore, one could take a colormap, switch on the greyscale attribute when desired (which would swap the two tables), and
Re: [matplotlib-devel] Colormap that prints nicely in black and white
On Tue, Aug 10, 2010 at 7:39 PM, Benjamin Root wrote: > On Tue, Aug 10, 2010 at 7:20 PM, Eric Firing wrote: > >> On 08/10/2010 11:58 AM, Friedrich Romstedt wrote: >> > 2010/8/10 Eric Firing: >> >> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote: >> >>> So I think it is probably best to code it into the Colormap object >> >>> itself, so that each and ever derived class can define its own method >> >>> of how to create a greyscale version. What do you think about that? >> >> >> >> Good idea. The base class could define a default to_grayscale() method >> >> that would do the conversion near the very end of the Colormap.__call__ >> >> method if an as_gray attribute, also defined in the base class, is >> True. >> >> No need for getters and setters--let it be a simple attribute. This >> >> is much simpler than generating a whole new colormap--instead, just set >> >> an attribute to switch an existing colormap to gray or back to color. >> I >> >> would leave the switch out of the __init__ args and kwargs. >> > >> >> If someone >> >> wants grey, they can add one more line of code to set the attribute. >> > >> > Hmm, one would have to do it for every colormap used. Also, it would >> > be not so obvious if using the default colormap. >> > >> >> I >> >> suspect only a small fraction of users will need this. >> > >> > I like this, it's a good idea enabling to not repeat all the stuff in >> > the code. But hey, wouldn't it be the same to just overload the >> > __call__ method? >> > >> > class GrayColorbar(RgbColorbar): >> > """A colorbar returning grayscaled version.""" >> > >> > def __call__(self, value): >> > """Transforms RgbColorbar's value into grayscale, and returns >> it. >> > >> > rgb = BaseClass.__call__(self, value) >> > [do stuff] >> > return grayscale >> >> Why make a whole new class instead of switching a behavior in an >> existing class? >> >> > >> > Agreed, one has to this for all the classes, while your solution works >> > generically in ColormapBase or whatever it's called. >> >> I think my solution (with slight modification) is also very compatible >> with your suggestion below to have an rc param that switches between >> color and gray. If as_gray is None, use the rc value; otherwise, let it >> act as described above. >> >> The typical use case is when one wants color initially, but then must >> regenerate plots in black and white to reduce publication costs. Your >> rc suggestion facilitates such switching. >> >> > >> > Another option would be, to wrap the Colormap into a thin layer with >> > __call__, but this appears way too clumsy and too hacky to me. It's a >> > clumsy way of deriving from the class. Otherwise it's maybe also >> > nice, because it's generic, for all Colormaps. __getattr__ and >> > __setattr__ (iirc) could be used to simulate the wrapped instance >> > fully. >> >> I don't follow you on this--I don't understand at all. >> >> >> > >> > Is there some layer dealing with colors in the renderers, where the >> > conversion could also happen? I'm asking because of displaying color >> > images etc. and printing them as grayscale. With this, we would get >> > rid of the alpha stuff completely, too. >> >> I don't understand why you would want to push this down into the >> renderers instead of keeping it at a higher level. And I don't know >> what you mean by "getting rid of the alpha stuff". >> >> > >> > Maybe a general matplotlib.rc switch 'greyscale' would be possible. >> > It would leave room for tons of improvement, e.g. automatically >> > setting the color cycle to - -- -. etc., there was some monthes ago >> > discussion about how to achieve that. Another advantage: It's zero >> > loc if set in the config file ;-) >> >> Yes, there does seem to be a need for these sorts of switching >> operations. Getting back to the colormap question, our discussions have >> been based on the assumption that an rgb_to_gray function is all that is >> needed. But is this true? Or will users actually need completely >> different graymaps rather than something resembling a black-and-white >> photo of a colormap? If so, then my suggested strategy is useless. >> >> Eric >> >> > >> > I think that would be a real neat new feature. >> > >> > I agree what's not needed is mixed greyscale and colour display in the >> > same Figure. >> > >> > Bear with me if my ideas are always too radical. >> > >> > Friedrich >> >> > I have to agree with Eric on this. Maybe I am just not understanding > Friedrich's thought process. > > If someone wants a specific greyscale colormapping, then they can make it > themselves just like any other colormap. However, it is as a matter of > convenience and ease to say "hey, I have this colormap that I have been > using in my code, but I need its greyscale equivalent". > > My idea is this. It appears that all colormappings get a lookup table > (self._lut) that contains rgba values. We could also simultaneously >
