Something that I’ve thought about for quite awhile but only now managed to get around to doing. I have added a new histogramming tool to GRASS 7, based on PyPlot like the profiling tool. It will histogram a single raster map or all the maps in an imagery group. It gives user control over colors and line styles, axes, legends, fonts, and grid.
It is available from the analysis toolbar button on the display canvas as “Create histogram with PyPlot” for now. I’ve left in the old tool that displays d.hist in a window. It should be especially useful for image analysis.
Give it a try and let me know if you hit any bugs.
Cheers
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
2011/9/22 Michael Barton <Michael.Barton@asu.edu>:
Something that I've thought about for quite awhile but only now managed to
get around to doing. I have added a new histogramming tool to GRASS 7, based
on PyPlot like the profiling tool. It will histogram a single raster map or
all the maps in an imagery group. It gives user control over colors and line
styles, axes, legends, fonts, and grid.
It is available from the analysis toolbar button on the display canvas as
"Create histogram with PyPlot" for now. I've left in the old tool that
displays d.hist in a window. It should be especially useful for image
analysis.
cool!
Give it a try and let me know if you hit any bugs.
yes, both Histogram and Histogram2() launched PyPlot-based
histogramming tool, fixed (including some cosmetics changes in
r48410).
I also worry about duplication of the code. Ideally
histogram.HistFrame and histogram2.HistFrame should have common
superclass. Same probably for histogram2.HistFrame and
profile.ProfileFrame.
I also worry about duplication of the code. Ideally
histogram.HistFrame and histogram2.HistFrame should have common
superclass. Same probably for histogram2.HistFrame and
profile.ProfileFrame.
similar implies for settings dialogs. Goal is to avoid duplication of
code as much as possible.
I'm not sure how you can get to histogram2 from anything other than the toolbar button menu. I've tried it from the image menu and from the original histogram toolbar button menu and get the original histogram tool. How else are you getting it to launch?
Histogram2 shares virtually nothing with Histogram code-wise. It is a completely different kind of module. However it does share a significant fraction of code with profile.py (which I used as a starting point). I'm thinking about a scatterplot tool for image analysis too. All 3 would use PyPlot and could in theory share considerable chunks of code.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
2011/9/22 Michael Barton <Michael.Barton@asu.edu>:
Something that I've thought about for quite awhile but only now managed to
get around to doing. I have added a new histogramming tool to GRASS 7, based
on PyPlot like the profiling tool. It will histogram a single raster map or
all the maps in an imagery group. It gives user control over colors and line
styles, axes, legends, fonts, and grid.
It is available from the analysis toolbar button on the display canvas as
"Create histogram with PyPlot" for now. I've left in the old tool that
displays d.hist in a window. It should be especially useful for image
analysis.
cool!
Give it a try and let me know if you hit any bugs.
yes, both Histogram and Histogram2() launched PyPlot-based
histogramming tool, fixed (including some cosmetics changes in
r48410).
I also worry about duplication of the code. Ideally
histogram.HistFrame and histogram2.HistFrame should have common
superclass. Same probably for histogram2.HistFrame and
profile.ProfileFrame.
At the moment, only the text dialog is the same between Histogram2 and Profile. The options dialog in Profile could be made to work like that in Histogram2, but not the other way around. The raster input dialogs are quite different and probably need to remain so.
Profile works on the assumption of having 3 maps to profile. And it needs code for drawing the profile transect on the map display and creating/modifying segment marker points.
Histogram2 can have a variable number of maps to histogram (from one theoretically up to the maximum number supported by i.group) and doesn't need transect drawing code or code for segment markers. Hence, the dictionaries for tracking parameters like line color and width are a bit simpler in Histogram2 (one less level so that the raster name rather than an index number main key) making it easier to keep track of a potentially larger number of raster maps.
Code for overall plot parameters (e.g., axes, grids, title fonts, etc) are identical across both histogram2 and profile because they use standard PyPlot calls.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
I also worry about duplication of the code. Ideally
histogram.HistFrame and histogram2.HistFrame should have common
superclass. Same probably for histogram2.HistFrame and
profile.ProfileFrame.
similar implies for settings dialogs. Goal is to avoid duplication of
code as much as possible.
2011/9/22 Michael Barton <Michael.Barton@asu.edu>:
I'm not sure how you can get to histogram2 from anything other than the toolbar button menu. I've tried it from the image menu and from the original histogram toolbar button menu and get the original histogram tool. How else are you getting it to launch?
I meant that "Create histogram of raster map" (map display toolbar)
launched PyPlot-based histogramming tool. It has been fixed.
Histogram2 shares virtually nothing with Histogram code-wise. It is a completely different kind of module. However it does share a significant fraction of code with profile.py (which I used as a starting point). I'm thinking about a scatterplot tool for image analysis too. All 3 would use PyPlot and could in theory share considerable chunks of code.
right, comparing code of histogram2.py and profile.py there is a
*significant* overlap. Abstract class for both ProfileFrame and
histogram2.HistFrame could significantly reduce the code and make it
much more easily to maintain.
2011/9/22 Michael Barton <Michael.Barton@asu.edu>:
At the moment, only the text dialog is the same between Histogram2 and Profile. The options dialog in Profile could be made to work like that in Histogram2, but not the other way around. The raster input dialogs are quite different and probably need to remain so.
Profile works on the assumption of having 3 maps to profile. And it needs code for drawing the profile transect on the map display and creating/modifying segment marker points.
Histogram2 can have a variable number of maps to histogram (from one theoretically up to the maximum number supported by i.group) and doesn't need transect drawing code or code for segment markers. Hence, the dictionaries for tracking parameters like line color and width are a bit simpler in Histogram2 (one less level so that the raster name rather than an index number main key) making it easier to keep track of a potentially larger number of raster maps.
Code for overall plot parameters (e.g., axes, grids, title fonts, etc) are identical across both histogram2 and profile because they use standard PyPlot calls.
everything leads to the suggestion that ProfileFrame and
histogram2.HistFrame should be inherited from the common super-class,
probably same for settings dialogs except of RasterSelect.