Limited release: DynamicProfile module

[Nocturnal]

http://www.carpephoton.com/index.php?option=com_content&view=article&id=11:pixinsight-profile-module&catid=5:modules&Itemid=8

Windows x64 and Linux x64 only right now.

[Nocturnal]

I'll probably add a win32 flavor on Monday. Linux32 when I get some assistance on how to make cross compiles working on Linux64 (separate thread). Not sure if I'll pursue FreeBSD compilation.

[Niall Saunders]

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?"

[Juan Conejero]

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  

[Nocturnal]

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?"

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.

[Nocturnal]

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

[Nocturnal]

Linux 64 and 32, Windows 64 and 32 now available.

[Niall Saunders]

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.

[Nocturnal]

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.

[Niall Saunders]

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

[Juan Conejero]

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.

[Nocturnal]

Hi Juan,

I doubt that I made up those naming conventions myself. Must have been copied from some other module. I'll change the names as I sure don't like them either. Still I doubt there will be many profile instances saved anywhere

[Juan Conejero]

Where the lenght of 'temporary' remains to be seen

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.

Still I doubt there will be many profile instances saved anywhere

Come on, you've written an extremely nice and useful tool. Bring up your self-esteem!!!

[Nocturnal]

Hi Juan

oh I'm pretty sure this is useful otherwise I wouldn't have spent hours slaving over it It's just that I do not think it's a process that will be part of saved process icon sets.

[Enzo De Bernardini]

Very good work, thanks. It is an interesting tool.

Enzo.