I did a "find / -name 'gwy.so' " and can't find it anywhere. It seems to
be missing.
Could I have missed a dependency and it just didn't get included in the
build. I checked the output from the configure and make and didn't see any
mention of gwy.so. I realized I didn't have pyGobject or PyCairo
installed, so I installed them from packages, but still no luck.
Message: 1
Date: Wed, 30 Oct 2013 22:17:32 +0100
From: David Ne?as (Yeti) <[email protected]>
Subject: Re: [Gwyddion-users] can't find gwy python module
To: Gwyddion use discussion <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On Wed, Oct 30, 2013 at 01:44:23PM -0400, Ramsey Hazbun wrote:
> A follow-up. I realize now that my compiled gwyddion is not working (the
> apt package did). I get the following error on start-up:
> Application and library version do not match: 2.33 vs. 2.31
> I imagine this is because I had the ubuntu package installed previously.
This is not a fatal error but it indicates something is amiss ? and
something else may fail later.
If you have a system package installed and also gwyddion compiled from
source code, and want to use the latter, it may be necessary to set a
few environment variables to ensure the compiled version takes
precedence. Namely you need to set LD_LIBRARY_PATH (to include the lib
directory), PYTHONPATH (to include the site-packages directory
containing gwy.so) and PATH.
Regards,
Yeti
On Wed, Oct 30, 2013 at 5:49 PM, <
[email protected]> wrote:
> Send Gwyddion-users mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/gwyddion-users
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gwyddion-users digest..."
>
>
> Today's Topics:
>
> 1. Re: can't find gwy python module (David Ne?as (Yeti))
> 2. Re: can't find gwy python module (Ramsey Hazbun)
> 3. Re: can't find gwy python module (David Ne?as (Yeti))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 30 Oct 2013 22:17:32 +0100
> From: David Ne?as (Yeti) <[email protected]>
> Subject: Re: [Gwyddion-users] can't find gwy python module
> To: Gwyddion use discussion <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=utf-8
>
> On Wed, Oct 30, 2013 at 01:44:23PM -0400, Ramsey Hazbun wrote:
> > A follow-up. I realize now that my compiled gwyddion is not working (the
> > apt package did). I get the following error on start-up:
> > Application and library version do not match: 2.33 vs. 2.31
> > I imagine this is because I had the ubuntu package installed previously.
>
> This is not a fatal error but it indicates something is amiss ? and
> something else may fail later.
>
> If you have a system package installed and also gwyddion compiled from
> source code, and want to use the latter, it may be necessary to set a
> few environment variables to ensure the compiled version takes
> precedence. Namely you need to set LD_LIBRARY_PATH (to include the lib
> directory), PYTHONPATH (to include the site-packages directory
> containing gwy.so) and PATH.
>
> Regards,
>
> Yeti
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 30 Oct 2013 17:34:53 -0400
> From: Ramsey Hazbun <[email protected]>
> Subject: Re: [Gwyddion-users] can't find gwy python module
> To: Ramsey Hazbun <[email protected]>
> Cc: gwyddion-users <[email protected]>
> Message-ID:
> <
> cacr-cdip5u1+zj2hy0jk6scgv6hty2o37cer13fydmlckmg...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I've come up with some improvements (IMO).
>
> The first script below is similar to the last, but:
> - gets the original filenames and appends "marked" for the exported
> filenames.
> - It also closes the files after export which gives some visual feedback
> that things are working.
> - On my computer it runs through ~50 files in about 5-10 seconds.
> - I also coded my way around the problem of not being able to change the
> mask color for the grain marking. Then I found the "Default Mask Color"
> setting. Whoops. So you could use the routine in the below script, or use
> the more straightforward code I used in the first script:
> gwy.gwy_process_func_run("grain_mark", c, gwy.RUN_INTERACTIVE)
> - the leveling does not work for some reason. but because I can mark the
> grains with full white or full black the thresholding algorithm of the
> other program I'm counting dots with works great. this should be easy to
> fix.
>
>
> So the big remaining issue is opening all the files and performing these
> operations. I was able to come up with a second script that traverses a
> directory and opens all the files in it. Unfortunately, it's still manual
> because I am working with BMP files, which can't import automatically. Is
> there a way to run the import window as NONINTERACTIVE? Or is there an
> image format I could convert to that would open automatically in Gwyddion?
> This is really the final piece I need to make this all work.
>
>
> Here are the scripts:
>
> SCRIPT 1 - Mark and export
>
> import gwyutils
>
>
> #basename =
> "c:\processed\sample%(sample_num)02d_marked_%(image_num)02d.png"
> basename = "c:/processed/%s-marked.png"
>
>
> i = 0
> num = 1
>
>
> # get list of available containers
>
>
> cons = gwy.gwy_app_data_browser_get_containers()
>
>
> # iterate thru containers and datafields
>
>
> for c in cons:
>
>
> # get directory of datafields where key is key in container
>
>
> dfields = gwyutils.get_data_fields_dir(c)
>
> for key in dfields.keys():
>
>
> # get processed datafield object
>
>
> datafield = dfields[key]
>
> # create new grainfield by using active datafield
> grainfield = datafield.new_alike(True)
>
> # retrieve datafield number in container from key (for example
> '/0/data')
>
>
> datafield_id = key.split('/')[1]
>
>
> # set palette of datafield
>
>
> c.set_string_by_name("/%s/base/palette" % datafield_id, "Gray")
>
> #get filename without directory or file extension
> filename = c.get_string_by_name('/filename')
> filename = filename.rsplit('\\',1)[1]
> filename = filename.rsplit('.',1)[0]
>
>
> # call 'level' process module as non-interactive DOESN'T WORK
> gwy.gwy_process_func_run("level", c, gwy.RUN_NONINTERACTIVE)
>
>
> # mark grains by threshold/slope
>
> #Generate grainfield
> datafield.grains_mark_slope(grainfield,15,0)
>
> #Merge two fields
> datafield.max_of_fields(datafield, grainfield)
>
>
> # request redraw before export
>
>
> datafield.data_changed()
>
>
> # export datafield to png, for the first time show export dialog
>
> # A generic naming/export routine
>
> # if i == 0:
>
> # gwyutils.save_dfield_to_png(c, key, basename %
> {"sample_num":num,"image_num":i+1}, gwy.RUN_INTERACTIVE)
>
> # else :
>
> # gwyutils.save_dfield_to_png(c, key, basename %
> {"sample_num":num,"image_num":i+1}, gwy.RUN_NONINTERACTIVE)
>
> # A little more specific naming routine. Preserves original filename
> in exported name.
> if i == 0:
>
> gwyutils.save_dfield_to_png(c, key, basename % filename,
> gwy.RUN_INTERACTIVE)
>
> else :
>
> gwyutils.save_dfield_to_png(c, key, basename % filename,
> gwy.RUN_NONINTERACTIVE)
>
>
> i += 1
>
>
> # request redraw datawindows with datafields
>
>
> datafield.data_changed()
>
> #Close container/window after export. Gives some visual feedback when
> dealing with large number of windows.
> gwy_app_data_browser_remove(c)
>
>
>
>
> SCRIPT 2 - Traverse directory
>
> import os, gwyutils, gwy
>
> directory = "C:\YOUR_DIRECTORY"
> print directory
>
> for dirname, dirnames, filenames in os.walk(directory):
> # print path to all subdirectories first.
> for subdirname in dirnames:
> print os.path.join(dirname, subdirname)
>
> # print path to all filenames.
> for filename in filenames:
> path = os.path.join(dirname, filename)
> print path
> print path.split(".")[-1].lower()
> if path.split(".")[-1].lower() in ['bmp']:
> print "BMP!"
> gwy_app_file_open(path)
>
>
>
> On Wed, Oct 30, 2013 at 2:39 PM, Ramsey Hazbun <
> [email protected]> wrote:
>
> > Since I kind of hit a wall with the standalone python script. Here is
> the
> > pygwy code I've written, based on the code posted on the pygwy tutorial.
> > I'm pretty close to a reasonable solution, but it won't be ideal, and
> it's
> > still a little too manual to be practical.
> >
> > Some problems I'm having:
> > - the mark grains dialog doesn't seem to run in NONINTERACTIVE mode. In
> > interactive mode, while it remembers the slope value I'd like to use, it
> > does not remember the color for the mask. This is critical for my work
> (I
> > am trying to count the grains). Perhaps there's a line or two I could
> use
> > to change the color of the grains after they are marked?
> > - In general it seems really difficult to pass parameters to these
> > functions. I'm guessing there are some more direct functions I should be
> > using and so far I've been using GUI/front-end version. I tried to get
> > gwy_data_field_grains_mark_slope () to work, but apparently I don't have
> it
> > quite right. Either I'm a bit clueless (likely), or the function is for
> C
> > and hasn't made it into the python implementation.
> > - I have no idea how to get grain counts or statistics into a text file
> of
> > some sort. I've been relying on another program I have that is great for
> > export dot/grain counts, but lacks the image processing that gwyddion
> has.
> > - I have to load all the images I want to process in the Gwyddion GUI. I
> > am planning on doing this about 50 files at a time. Obviously a
> standalone
> > script would be ideal but in lieu of that, this console script is the
> best
> > option I have at the moment.
> > - export doesn't work if directory doesn't exist. this is trivial, and
> > probably could be fixed by some python code to look for the directory and
> > create it if it's missing.
> >
> > START CODE
> >
> > import gwyutils
> >
> > # base name
> > basename =
> "c:\processed\sample%(sample_num)02d_marked_%(image_num)02d.png"
> >
> > i = 0
> > num = 1
> >
> > # get list of available containers
> > cons = gwy.gwy_app_data_browser_get_containers()
> >
> > # iterate thru containers and datafields
> > for c in cons:
> >
> > # get directory of datafields where key is key in container
> > dfields = gwyutils.get_data_fields_dir(c)
> >
> > for key in dfields.keys():
> >
> > # get processed datafield object
> > datafield = dfields[key]
> >
> > # retrieve datafield number in container from key (for example
> > '/0/data')
> > datafield_id = key.split('/')[1]
> >
> > # set palette of datafield
> > c.set_string_by_name("/%s/base/palette" % datafield_id, "Gray")
> >
> > # call 'level' process module as non-interactive
> > gwy.gwy_process_func_run("level", c, gwy.RUN_NONINTERACTIVE)
> >
> > # mark grains by threshold/slope
> > # if i == 0:
> > # gwy.gwy_process_func_run("grain_mark", c, gwy.RUN_INTERACTIVE)
> > # else :
> > # gwy.gwy_process_func_run("grain_mark", c,
> gwy.RUN_NONINTERACTIVE)
> > gwy.gwy_process_func_run("grain_mark", c, gwy.RUN_INTERACTIVE)
> >
> > # request redraw before export
> > datafield.data_changed()
> >
> > # export datafield to png, for the first time show export dialog
> >
> > if i == 0:
> > gwyutils.save_dfield_to_png(c, key, basename %
> > {"sample_num":num,"image_num":i+1}, gwy.RUN_INTERACTIVE)
> > else :
> > gwyutils.save_dfield_to_png(c, key, basename %
> > {"sample_num":num,"image_num":i+1}, gwy.RUN_NONINTERACTIVE)
> >
> > i += 1
> >
> > # request redraw datawindows with datafields
> > datafield.data_changed()
> >
> >
> > On Wed, Oct 30, 2013 at 1:44 PM, Ramsey Hazbun <
> > [email protected]> wrote:
> >
> >> A follow-up. I realize now that my compiled gwyddion is not working
> (the
> >> apt package did). I get the following error on start-up:
> >> Application and library version do not match: 2.33 vs. 2.31
> >> I imagine this is because I had the ubuntu package installed previously.
> >>
> >>
> >>
> >> On Wed, Oct 30, 2013 at 1:21 PM, Ramsey Hazbun <
> >> [email protected]> wrote:
> >>
> >>> I'm attempting to write a standalone python script to process about a
> >>> thousand images. I simply want to level and mark grains based on known
> >>> slope. From what I've seen and tried in pygwy this seems doable.
> >>>
> >>> I'm having a series of problems that have led me to this point.
> >>> - I started on windows. So no standalone gwy module for python
> >>> available. That much I read on the mailing lists. Not too worried
> since
> >>> I'm fine with using Linux. But less convenient.
> >>> - I went over to Ubuntu, but the gwyddion apt package (based on
> gwyddion
> >>> 2.31) doesn't seem to include the python gwy module.
> >>> - I installed the gtk devel package and compiled gwyddion 2.33 from
> >>> scratch using ./configure --with-python
> >>>
> >>> As you might of guessed I'm getting an error when I try to import the
> >>> gwy module in python:
> >>> ImportError: no module named gwy
> >>>
> >>> So what am I missing here? Let me know what additional info you might
> >>> need. I'm on Ubuntu 13.10.
> >>>
> >>> Also, thanks for all the hard work. I'm already assuming Yeti is going
> >>> to respond to me based on all the other messages I've read on these
> >>> gwyddion/python issues.
> >>>
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 30 Oct 2013 22:48:50 +0100
> From: David Ne?as (Yeti) <[email protected]>
> Subject: Re: [Gwyddion-users] can't find gwy python module
> To: Gwyddion use discussion <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Oct 30, 2013 at 02:39:02PM -0400, Ramsey Hazbun wrote:
> > - the mark grains dialog doesn't seem to run in NONINTERACTIVE mode.
>
> The run mode nomenclature is a bit confusing. NONINTERACTIVE is used
> for file modules; IMMEDIATE is the more or less equivalent for
> processing modules, see
>
>
> http://gwyddion.net/documentation/libgwymodule/libgwymodule-gwymoduleenums.php#GwyRunType
>
> > it does not remember the color for the mask.
>
> Mask colour can be set by setting "/0/mask/red", "/0/mask/green" and
> "/0/mask/blue" (for channel 0).
>
> > This is critical for my work (I am trying to count the grains).
>
> Grain counting is done by gwy_data_field_number_grains().
> Unfortunately, this has a C interface that does not automatically
> translate to Python as it works with plain C arrays. So someone would
> have to write a wrapper function...
>
> > - In general it seems really difficult to pass parameters to these
> > functions. I'm guessing there are some more direct functions I should be
> > using and so far I've been using GUI/front-end version. I tried to get
> > gwy_data_field_grains_mark_slope () to work, but apparently I don't have
> it
> > quite right. Either I'm a bit clueless (likely), or the function is for
> C
> > and hasn't made it into the python implementation.
>
> This one should work fine in Python. This marks slopes above 50% for
> me in the console:
>
> f = gwy.gwy_app_data_browser_get_current(gwy.APP_DATA_FIELD)
> m = gwy.gwy_app_data_browser_get_current(gwy.APP_MASK_FIELD)
> f.grains_mark_slope(m, 50.0, False)
> m.data_changed()
>
> > - I have no idea how to get grain counts or statistics into a text file
> of
> > some sort. I've been relying on another program I have that is great for
> > export dot/grain counts, but lacks the image processing that gwyddion
> has.
>
> The raw grain data export of grain_dist requires to enter the file name
> in the GUI. Doing the same thing this module does manually again
> apparently fails due to the unavailability of number_grains() (and
> apparently at least also gwy_grain_values_calculate() which also does
> not translate automatically to Python).
>
> The Python interface suffers from the fact I don't use it as I'm happy
> with C. So only rarely missing functions which do not translate
> automatically from C and need wrappers in wrap_calls.c are added...
>
> Regards,
>
> Yeti
>
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> Gwyddion-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gwyddion-users
>
>
> End of Gwyddion-users Digest, Vol 79, Issue 6
> *********************************************
>
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Gwyddion-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gwyddion-users
