Limited release: DynamicProfile module
- Thread starter Nocturnal
- Start date
ixinsight-profile-module&catid=5:modules&Itemid=8Niall Saunders
Well-known member
Thanks for that Sander,
Interesting to see your final sentence - and that is NOT by way of criticism. (Presumably this allows you to control the release in much the same way as PI 'core' was released?)
Due to all my HDD and RAID problems I haven't bothered to download it (yet), but did have one question straight away, "How easily could the module be modified to allow the graph to be saved as a 'native' PI image?" I only ask because I immediately thought "How can I 'compare' two star profiles 'side-by-side'?", or "What about comparing, for example, an x-axis and y-axis profile of the same star?"
Interesting to see your final sentence - and that is NOT by way of criticism. (Presumably this allows you to control the release in much the same way as PI 'core' was released?)
Due to all my HDD and RAID problems I haven't bothered to download it (yet), but did have one question straight away, "How easily could the module be modified to allow the graph to be saved as a 'native' PI image?" I only ask because I immediately thought "How can I 'compare' two star profiles 'side-by-side'?", or "What about comparing, for example, an x-axis and y-axis profile of the same star?"
Hi Sander,
A neat and useful tool - congratulations!
Niall has been faster than me in proposing a feature that is very necessary in my opinion. Actually, this task is easy to implement. You already have a drawing routine that plots the profile on a graphics context: either a Graphics or a VectorGraphics instance. You can associate a graphics context to a Bitmap, then render the Bitmap on a Generic2DImage<P>, which can be a window's MainView().Image(). In fact, I am planning to do exactly this with HistogramTransformation, or perhaps a new lightweight histogram visualization tool a la Statistics.
Another suggestion is saving the graphic as a SVG file. Again, PCL provides you with all the necessary tools: you can associate a graphics context to a SVG instance, so once more you can reuse your current drawing routine. SVG is great to embed graphics in documents.
I have more ideas. Currently when an instance of DynamicProfile is executed on a view nothing happens (e.g., when an icon is dragged to a view). I don't know if you have plans to implement a specific behavior, but if you implement Niall's suggestion, then a nice way to deal with view execution (your .ExecuteOn( View& ) member function) would creating a new 8-bit image with the profile graphic.
And now something that I think is really important. Currently you always rescale the profile to fit the available graphics port on the interface. This is a nice default behavior because it maximizes detail visibility. However, this has an important drawback: comparison of several profiles is difficult due to the varying vertical scales. I would add an option to "fix" the vertical scale so a set of profiles can be plotted with the same units in samples/pixel. Or you could allow the user to define three scaling modes:
- Auto: profiles are automatically scaled to fit the graph's height (current mode).
- Normalized: the graph's height represents the normalized [0,1] range.
- Custom: the user specifies a custom plotting range in [0,1]. In this mode some profiles can get clipped, depending on the specified minimum and maximum plotting bounds and the sampled pixel values.
That's all, for now. As you see I'm good at figuring ways to make others work >
A neat and useful tool - congratulations!
Niall has been faster than me in proposing a feature that is very necessary in my opinion. Actually, this task is easy to implement. You already have a drawing routine that plots the profile on a graphics context: either a Graphics or a VectorGraphics instance. You can associate a graphics context to a Bitmap, then render the Bitmap on a Generic2DImage<P>, which can be a window's MainView().Image(). In fact, I am planning to do exactly this with HistogramTransformation, or perhaps a new lightweight histogram visualization tool a la Statistics.
Another suggestion is saving the graphic as a SVG file. Again, PCL provides you with all the necessary tools: you can associate a graphics context to a SVG instance, so once more you can reuse your current drawing routine. SVG is great to embed graphics in documents.
I have more ideas. Currently when an instance of DynamicProfile is executed on a view nothing happens (e.g., when an icon is dragged to a view). I don't know if you have plans to implement a specific behavior, but if you implement Niall's suggestion, then a nice way to deal with view execution (your .ExecuteOn( View& ) member function) would creating a new 8-bit image with the profile graphic.
And now something that I think is really important. Currently you always rescale the profile to fit the available graphics port on the interface. This is a nice default behavior because it maximizes detail visibility. However, this has an important drawback: comparison of several profiles is difficult due to the varying vertical scales. I would add an option to "fix" the vertical scale so a set of profiles can be plotted with the same units in samples/pixel. Or you could allow the user to define three scaling modes:
- Auto: profiles are automatically scaled to fit the graph's height (current mode).
- Normalized: the graph's height represents the normalized [0,1] range.
- Custom: the user specifies a custom plotting range in [0,1]. In this mode some profiles can get clipped, depending on the specified minimum and maximum plotting bounds and the sampled pixel values.
That's all, for now. As you see I'm good at figuring ways to make others work >
Niall Saunders said:
Hi Niall,
yes, since PCL is now forward compatible (a terrific feature by the way) I wanted to put a time bomb in the module in case I decide to start charging for it. Your idea is a good one. While I figure out how to do that (with Juan's help below) you can use something like IrfanView to to take screenshots of PI. That will allow you to compare right now. CVS export may also be useful.
Hi Juan,
thanks for the suggestions on how to implement Niall's idea.
I see that process execution doesn't quite work. When you drag a process icon to the workspace and drag that to an image it'll show the profile. When the icon gets dragged straight to an image it does not. Hmm. Frankly those are the most difficult things to figure out about PCL. So many hooks and events. No document that describes the event model and maps it to the user experience
thanks for the suggestions on how to implement Niall's idea.
I see that process execution doesn't quite work. When you drag a process icon to the workspace and drag that to an image it'll show the profile. When the icon gets dragged straight to an image it does not. Hmm. Frankly those are the most difficult things to figure out about PCL. So many hooks and events. No document that describes the event model and maps it to the user experience
Niall Saunders
Well-known member
Hi Sander,
Yes, the in-built ability to create an image would certainly be 'simpler' that some third-party screen-capture utility. In fact, I have even thought about 'superimposing' of curves and how that might be implemented in your code - and the ability to add to an existing image without the use of a 'CLS' (or equivalent) command first was how I foresaw the solution.
All of this is always due to the fact that different users are going to want to try and analyse their data in different ways, each looking for some sort of 'angle' that helps them differentiate between data sets.
And, yes, I figured out that your 'time-bomb' was to keep you in control of the code. Even without the commercial implications, it also lets you ensure that users ARE working with recent compilations - and that is a very useful 'control' for the author to have as well. Personally, I have no problems with what you have done. After all we have had an ongoing open Forum discussion in place for a while now, so prospective users should be more than aware of how things may move forward in the future. Best of luck to you.
Yes, the in-built ability to create an image would certainly be 'simpler' that some third-party screen-capture utility. In fact, I have even thought about 'superimposing' of curves and how that might be implemented in your code - and the ability to add to an existing image without the use of a 'CLS' (or equivalent) command first was how I foresaw the solution.
All of this is always due to the fact that different users are going to want to try and analyse their data in different ways, each looking for some sort of 'angle' that helps them differentiate between data sets.
And, yes, I figured out that your 'time-bomb' was to keep you in control of the code. Even without the commercial implications, it also lets you ensure that users ARE working with recent compilations - and that is a very useful 'control' for the author to have as well. Personally, I have no problems with what you have done. After all we have had an ongoing open Forum discussion in place for a while now, so prospective users should be more than aware of how things may move forward in the future. Best of luck to you.
Hi Niall,
yes, I only suggested the capture mechanism as a temporary workaround. Where the lenght of 'temporary' remains to be seen I think there's more benefit to re-implementing my hot/cold pixel and bad column repair tool so I may do that first. Kind of depends on how bored I am the next few days.
yes, I only suggested the capture mechanism as a temporary workaround. Where the lenght of 'temporary' remains to be seen
I think there's more benefit to re-implementing my hot/cold pixel and bad column repair tool so I may do that first. Kind of depends on how bored I am the next few days.Niall Saunders
Well-known member
Hey Sander,
If you are really bored, can I send you my NAS RAID array to see if you can get it to rebuild from two 1TB drives, EACH with damaged sectors? Right now it seems to be 'under control', in that I have just ordered a shotgun and a box of deer slugs. Me and some silicon are about to go to WAR >
If you are really bored, can I send you my NAS RAID array to see if you can get it to rebuild from two 1TB drives, EACH with damaged sectors? Right now it seems to be 'under control', in that I have just ordered a shotgun and a box of deer slugs. Me and some silicon are about to go to WAR >
Hi Sander,
A couple recommendations. I see that your process has parameter identifiers such as CurveType, EndXParameter, EndYParameter, etc. While this is perfectly acceptable in PCL, I strongly recommend you to change these identifiers to curveType, endX, endY, etc. Do this now that you still don't have thousands of instances of DynamicProfile living out there; it will be much harder in a couple days (no actual problem though, as you can use parameter aliases to support old parameter names; see the MetaParameter::Aliases() member function. However, it's always better if you don't have to use them)
On one hand, suffixing each parameter with 'Parameter' doesn't add too much legibility to script codifications of your process, as it is pretty obvious that these properties are parameters
On the other hand, it is customary practice to name all properties with initial lowercase words in JavaScript. The same rule is also followed in PCL and all standard processes.
Just a suggestion.
A couple recommendations. I see that your process has parameter identifiers such as CurveType, EndXParameter, EndYParameter, etc. While this is perfectly acceptable in PCL, I strongly recommend you to change these identifiers to curveType, endX, endY, etc. Do this now that you still don't have thousands of instances of DynamicProfile living out there; it will be much harder in a couple days
(no actual problem though, as you can use parameter aliases to support old parameter names; see the MetaParameter::Aliases() member function. However, it's always better if you don't have to use them)On one hand, suffixing each parameter with 'Parameter' doesn't add too much legibility to script codifications of your process, as it is pretty obvious that these properties are parameters
On the other hand, it is customary practice to name all properties with initial lowercase words in JavaScript. The same rule is also followed in PCL and all standard processes.
Just a suggestion.
Big mistake, in my opinion. Improving and polishing DynamicProfile will teach you a wealth of things about PCL programming, especially about dynamic interfaces and graphics generation. And I do think this tool is really useful. You know I'm here to help you as needed.
Come on, you've written an extremely nice and useful tool. Bring up your self-esteem!!!
Enzo De Bernardini
PixInsight Ambassador
Very good work, thanks. It is an interesting tool.
Enzo.
Enzo.
Nocturnal said:
Ah yes. Does the following look familiar?
Code:
CropProcess::CropProcess() : MetaProcess()
{
TheCropProcess = this;
// Instantiate process parameters
new LeftMargin( this );
new TopMargin( this );
new RightMargin( this );
new BottomMargin( this );
TheCroppingModeParameter = new CroppingMode( this );
TheXResolutionCropParameter = new XResolution( this );
TheYResolutionCropParameter = new YResolution( this );
TheMetricResolutionCropParameter = new MetricResolution( this );
TheForceResolutionCropParameter = new ForceResolution( this );
TheFillRedCropParameter = new FillRed( this );
TheFillGreenCropParameter = new FillGreen( this );
TheFillBlueCropParameter = new FillBlue( this );
TheFillAlphaCropParameter = new FillAlpha( this );
}Hi Sander,
The problem is in your reimplementations of:
not in the identifiers of your parameters and variables; these are private to your module. It is MetaParameter::Id() what is exported for each process parameter.
The problem is in your reimplementations of:
Code:
IsoString MetaParameter::Id() constnot in the identifiers of your parameters and variables; these are private to your module. It is MetaParameter::Id() what is exported for each process parameter.
Yuriy Toropin
Well-known member
This thread has been dead for almost 6 years now, anyway -
is there some other working PI process or script that can build 2D Plots (profiles) of arbitrary length and direction?
Will appreciate any help!
Update: it seems that the 2DPlot script still works! Great!
is there some other working PI process or script that can build 2D Plots (profiles) of arbitrary length and direction?
Will appreciate any help!
Update: it seems that the 2DPlot script still works! Great!