[Matplotlib-users] image display conventions

[Perry Greenfield <perry@st...>]

I'm wondering about whether the convention that matplotlib 
adopts for image display is the the standard expected for
science and engineering. When an image is displayed,
index 0,0 appears at the top left. While that is the standard
conventions for most computer graphics, it isn't in astronomy 
(we usually expect it to be bottom left). Are there others
that expect the way it behaves now? 

While I'm at it, does anyone else need to display images as
raw pixel dumps (every pixel in the image matches the
display pixel) without trying to match axes? This is very
common in astronomy (I understand that this is effectively
not really using matplotlib to do graphics, but rather as
a simple image display window, but this is something
astronomers are used to doing for data inspection, and
it would be nice to be able to do this within matplotlib as it
is for IDL). My guess is that a raw image display function
would be figure-oriented (as opposed to axes-oriented as it
is for the current one).

Perry

Re: [Matplotlib-users] solaris compilation

[John Hunter <jdhunter@ac...>]

>>>>> "Kuzminski," == Kuzminski, Stefan R <SKuzminski@...> writes:

    Kuzminski> I got it to go on Solaris, but I keep hitting a seg
    Kuzminski> fault on the creation of the FT2Font object around
    Kuzminski> line 261 in backend_agg.py.  It ran when I put a print
    Kuzminski> in before the creation of the FT2Font object.  That's
    Kuzminski> right.  Something spooky like that means to me that
    Kuzminski> there is a bug in ft2font.c where some variable is not
    Kuzminski> initialized correctly and the extra print leaves the
    Kuzminski> right patch of initialized memory so it runs.  Only
    Kuzminski> way to really nail something like that is with a
    Kuzminski> Purify or Valgrind like tool.

Thanks for the additional information.  This one is a little harder
for me to debug since I can't replicate it.  I recently rewrote the
agg backend using cxx which is really nice, and a hell of a lot easier
than doing the extension code by hand.  I may do the same for
ft2font.

In the meantime, if you have some free time to either run a debugger
or just insert some sporadic prints in newFT2FontObject that would
help narrow where the segfault is occurring.

Something like


static FT2FontObject *
newFT2FontObject(PyObject *args)
{
  int error;
  char* facefile;
  printf("initializing\n");
  if (! _initLib) { 
    error = FT_Init_FreeType( &_ft2Library ); //initialize library 

    if (error) {
      PyErr_SetString(PyExc_RuntimeError, 
		      "Could not find initialize the freetype2 library");
      return NULL;
    }
    _initLib = 1;

  }

  printf("parsing args\n");  
  if (!PyArg_ParseTuple(args, "s:FT2Font", &facefile))
    return NULL;

  
  printf("creating object\n");  
  FT2FontObject *self;
  self = PyObject_New(FT2FontObject, &FT2Font_Type);
  self->image.buffer = NULL;
  self->text = NULL;
  self->num_glyphs = 0;
  FT2Font_clear(self);

  printf("new face\n");  
  error = FT_New_Face( _ft2Library, facefile, 0, &self->face );
  if (error == FT_Err_Unknown_File_Format ) {
    
    set_error(PyExc_RuntimeError,
	      "Could not load facefile %s; Unknown_File_Format", facefile);
    return NULL;
  }
  else if (error == FT_Err_Cannot_Open_Resource) {
    
    set_error(PyExc_RuntimeError,
	      "Could not open facefile %s; Cannot_Open_Resource", facefile);
    return NULL;
  }
  else if (error == FT_Err_Invalid_File_Format) {
    
    set_error(PyExc_RuntimeError,
	      "Could not open facefile %s; Invalid_File_Format", facefile);
    return NULL;
  }
  else if (error) {
    set_error(PyExc_RuntimeError,
	      "Could not load face file %s; freetype error code %d", facefile, error);
    return NULL;

  }
  printf("setting size\n");  
  // set a default fontsize 12 pt at 72dpi
  error = FT_Set_Char_Size( self->face, 12 * 64, 0, 72, 72 );
  if (error) {
    PyErr_SetString(PyExc_RuntimeError, 
		    "Could not set the fontsize");
    return NULL;
  }
  

  printf("initing dict\n");  
  if (self == NULL)
    return NULL;
  self->x_attr = NULL;

  printf("getting ps name\n");    
  // set some face props as attributes
  const char*  ps_name;
  ps_name = FT_Get_Postscript_Name( self->face );
  if ( ps_name == NULL )
    ps_name = "UNAVAILABLE";

  printf("setting attributes\n");        
  SETATTR(self, FT2Font_setattr, "postscript_name", PyString_FromString, ps_name);
  SETATTR(self, FT2Font_setattr, "num_faces",       PyInt_FromLong,      self->face->num_faces);
  SETATTR(self, FT2Font_setattr, "family_name",     PyString_FromString, self->face->family_name);
  SETATTR(self, FT2Font_setattr, "style_name",      PyString_FromString, self->face->style_name);
  SETATTR(self, FT2Font_setattr, "face_flags",      PyInt_FromLong,      self->face->face_flags);
  SETATTR(self, FT2Font_setattr, "style_flags",     PyInt_FromLong,      self->face->style_flags);
  SETATTR(self, FT2Font_setattr, "num_glyphs",      PyInt_FromLong,      self->face->num_glyphs);
  SETATTR(self, FT2Font_setattr, "num_fixed_sizes", PyInt_FromLong,      self->face->num_fixed_sizes);
  SETATTR(self, FT2Font_setattr, "num_charmaps",    PyInt_FromLong,      self->face->num_charmaps);


  printf("checking scalable\n");        
  int scalable;
  scalable = FT_IS_SCALABLE( self->face );
  SETATTR(self, FT2Font_setattr, "scalable", PyInt_FromLong, scalable);

  if (scalable) {
    SETATTR(self, FT2Font_setattr, "units_per_EM", PyInt_FromLong, self->face->units_per_EM);

  printf("building bbox\n");        
    PyObject *bbox = Py_BuildValue
      ("(llll)", 
       self->face->bbox.xMin, self->face->bbox.yMin, 
       self->face->bbox.xMax, self->face->bbox.yMax );
    SETATTR_PYOBJ(self, FT2Font_setattr, "bbox",  bbox);
    SETATTR(self, FT2Font_setattr, "ascender",            PyInt_FromLong, self->face->ascender);
    SETATTR(self, FT2Font_setattr, "descender",           PyInt_FromLong, self->face->descender);
    SETATTR(self, FT2Font_setattr, "height",              PyInt_FromLong, self->face->height);
    SETATTR(self, FT2Font_setattr, "max_advance_width",   PyInt_FromLong, self->face->max_advance_width);
    SETATTR(self, FT2Font_setattr, "max_advance_height",  PyInt_FromLong, self->face->max_advance_height);
    SETATTR(self, FT2Font_setattr, "underline_position",  PyInt_FromLong, self->face->underline_position);
    SETATTR(self, FT2Font_setattr, "underline_thickness", PyInt_FromLong, self->face->underline_thickness);
    
  }
  printf("made it!\n");        
  return self;
}

[Matplotlib-users] solaris compilation

[Kuzminski, Stefan R <SKuzminski@fa...>]

small bug..  line 237 in text.py, needs a str() around the 'legal' tuple
in the exception.

=20

bigger potential bug..

=20

I got it to go on Solaris, but I keep hitting a seg fault on the
creation of the FT2Font object around line 261 in backend_agg.py.  It
ran when I put a print in before the creation of the FT2Font object.
That's right.  Something spooky like that means to me that there is a
bug in ft2font.c where some variable is not initialized correctly and
the extra print leaves the right patch of initialized memory so it runs.
Only way to really nail something like that is with a Purify or Valgrind
like tool.=20

=20

S

RE: [Matplotlib-users] solaris compilation

[Kuzminski, Stefan R <SKuzminski@fa...>]

I installed freetype-2.1.8, libpng-1.2.5 and zlib.  I can compile and
install fine, but I get a segmentation fault when I try to run a simple
example.  I tracked it down a bit and it's happening on import when
creating the fonts, in font_manager.py line 384..

               font =3D ft2font.FT2Font(fname)

It processes timesi.ttf ok, but any of the other fonts in
share/matplotlib cause a segmentation fault.  I don't have a
.matplotlibrc, is there something in there that I should have set?

thanks,
S=20

-----Original Message-----
From: John Hunter [mailto:jdhunter@...]=20
Sent: Friday, May 07, 2004 6:42 AM
To: Kuzminski, Stefan R
Cc: matplotlib-users@...
Subject: Re: [Matplotlib-users] solaris compilation

>>>>> "Kuzminski," =3D=3D Kuzminski, Stefan R <SKuzminski@...>
writes:

    Kuzminski> I'm trying to install 0.53.1 on solaris and am getting
    Kuzminski> this compile error.  Looks like it needs the file
    Kuzminski> ft2build.h, but I don't see it anywhere..

You need to make sure a recent version of freetype (we recommend 2.1.7
or later) is installed on your system (and zlib and png for that
matter).  If it is installed, you need to make sure you add the base
install dir to your basedir list in setupext.py.  Eg if it is
installed to /some/dir/freetype2 you need to add /some/dir to
basedir['sunos5'] in that file; (I'm assuming sys.platform returns
'sunos5').

Where do the GNU tools for solaris go by default; something like
/freeware?  I'm referring to the collection from
http://wwws.sun.com/software/solaris/freeware/download.html. I can't
recall but whatever the base install dir is, we should add this dir to
the default sunos5 basedir list.

Finally, please submit back the required changes you made to
seteupext.py (if any) so we can fix this.

Hell, you got gdmodule compiled on win32; matplotlib on solaris should
be a cake walk :-)

Thanks,
John Hunter

Re: [Matplotlib-users] Date plotting

[John Hunter <jdhunter@ac...>]

>>>>> "Steve" == Steve Chaplin <stevech1097@...> writes:

    Steve> On Sat, 2004-05-08 at 20:47, John Hunter wrote:
    >> ax = subplot(111)
    >> 
    >> #your plot here for tick in ax.xaxis.get_minor_ticks():
    >> tick.label1.set_y(-0.1)
    >> 

    Steve> Thanks for the advice, but I tried this and the tick labels
    Steve> disappeared completely. I then tried tick.label1.set_y(0.0)
    Steve> which I would expect to leave the labels at the same place,
    Steve> but the labels disappeared also.

Doh!  There's a reason I try to never post untested code.  I wrongly
assumed the location were in relative axes coords but they are not.  I
use reference values (matplotlib.transforms.RRef - think mutable
floats or a c pointer to a float) in some instances to specify
locations.  I define binary operations on these so I can specify
locations like 3 points to the left of the x axis minimum, and have
these locations update automagically under figure resizes and dpi
changes - see http://matplotlib.sf.net/matplotlib.transforms.html.

This is what I do for x tick label locations - they are specified in
number of points below the minimum of the axes bounding rectangle.
Here is how to properly change that location (tested this time!)

from matplotlib.transforms import RRef
from matplotlib.matlab import *
ax = subplot(111)

plot([1,2,3])

points = 20
for tick in ax.xaxis.get_major_ticks():
    y = ax.bbox.y.get_refmin() - ax.dpi*RRef(points/72.0)
    tick.label1.set_y(y)
show()

ax.bbox.y.get_refmin(), ax.dpi and RRef(points/72.0) are all RRefs, as
is y.  

A word of warning.  I'm totally rewriting the transform architecture
from the ground up as we speak, so whatever you do here is likely to
change with the next release.  Of course there will be an analogous
way to do it and if you remind me I'll let you know what it is - or
you can check the code in XAxis.py to see how it specifies tick
locations.  In any case there will be release notes detailing the
changes.

    Steve> I had a look at matplotlib.dates and found what looks like
    Steve> a problem/limitation.  This is my understanding, which may
    Steve> be completely wrong.  The python 'time' module (and
    Steve> epochtime) limits years to 1970-2038.  The 'egenix' and
    Steve> python 'datetime' modules support a much larger range of
    Steve> years ('datetime supports years from 1-9999).

    Steve> matplotlib.dates converter classes supports 'epochtime',
    Steve> 'datetime' and 'egenix' date formats. However, internally
    Steve> it uses epochtime for all dates and so limits all years to
    Steve> the range 1970-2038, even though 'datetime' and 'egeinx'
    Steve> themselves support much more that this.

    Steve> I think there is a lot of data available before 1970 that
    Steve> people might like to plot. Taking stock data as an example,
    Steve> Yahoo has data going back to 1962 for some companies.

Absolutely right.  It ought to use datetime for everything if
python2.3 is available.  It's not a top priority for me right now
since I'm up to my elbows with the new transformation code, optimized
line and patch collection drawing, porting mathtext to PS and handling
newline separated strings, but I agree it is an important fix; I added
it to the priorities list.

JDH