New Reference Documentation Released

[Juan Conejero]

Hi all,

With the latest updates we have released new documentation for the following standard tools:

- DynamicPSF
- DynamicCrop
- IntegerResample
- FastRotation
- Rotation

If your PixInsight installation is up to date, you'll find these documents available on the Process Explorer window, as usual (to read them online you need a SVG/CSS3 capable browser such as Firefox 4 or higher, Safari >= 4, Opera >= 11, or MS Internet Explorer 9).

We have also released a new specific document to describe the pixel interpolation algorithms available on the PixInsight/PCL platform, with more technical information than previous releases. It is available as a related document from several geometrical tool documents: Resample, DynamicCrop, Rotation, etc.

The rest of documents available have been revised and updated to reflect recent changes in the implementations. This includes mainly ColorCalibration and BackgroundNeutralization. Numerous minor errors and some imprecise descriptions have also been fixed.

For developers, we have also released a new version of the documentation compiler script, 1.3.3, with many bug fixes, important new features in the PIDoc markup language, and improved document generation capabilities. We'll release an updated documentation for the PIDoc compiler within the next days.

Here is a list of the standard tools that are now documented:

Annotation
AssistedColorCalibration
BackgroundNeutralization
ChannelCombination
ChannelExtraction
ColorCalibration
Crop
CurvesTransformation
Debayer
DynamicCrop
DynamicPSF
FastRotation
HistogramTransformation
IntegerResample
LocalHistogramEqualization
RangeSelection
Resample
Rotation
ScreenTransferFunction

In addition, these development tools by Georg Viehoever are also documented:

GradientsHdrComposition
GradientsHdrCompression
GradientsMergeMosaic

The list is still small, that's true, but we are working almost exclusively on writing documentation now, so I hope it will grow during the next weeks/months. Our priority is to document some of the most complex and rich tools first, as we have done with DynamicPSF and DynamicCrop in this release.

Please note that we are stopping development of some important new tools and application features with this policy change. We are also slowing down production of new video tutorials. This will damage our position against competing products in the short-medium term, so I hope this is what a majority of users really want us to do. This is what we have understood from the criticism we have received recently. Thanks for your attention.

[sleshin]

Hi Juan,

we are working almost exclusively on writing documentation

I enthusiastically endorse and support this important change in priorities. Thanks.

Steve

[georg.viehoever]

....Please note that we are stopping development of some important new tools and application features with this policy change. We are also slowing down production of new video tutorials. This will damage our position against competing products in the short-medium term, so I hope this is what a majority of users really want us to do. This is what we have understood from the criticism we have received recently. Thanks for your attention.

I am so glad about this! I am quite convinced that this will not damage your position against competing products...finally your users will be able to discover the rich set of features that PI already has - without guessing.

Georg

[FunTomas]

Hi Juan.

Thank you very much for this important step. PixInsight is for me still like Excel. I know and I am using only about 5-10% capabilities.

Tomáš

[zvrastil]

That's great news! Thanks a lot. I'm looking forward to read it (really, no kidding - the quality of PixInsight documentation once released is so excellent that it's pleasure to read it and explore unforseen possibilities).

And I'm pretty sure it will help PixInsight against competing products, at least guessing by my personal experience. I evaluated PixInsight Standard twice (first like three of four years ago, then year ago). The main reason for rejecting it during my first trial was lack of any kind of documentation (reference, tutorials or anything) - there was simply not enough evidence for me it's worth the money (or development effort in my case). What brought me back was in fact the documentation again - Rogelio's tutorials and his unofficial reference gave me what I needed - overview of how many useful things are there and assurance I can find help if I need to.

best regards, Zbynek

[RBA]

This will damage our position against competing products in the short-medium term [..]

Not when you're competing against products that release documentation of their new developments along with the release of such new developments (not that I see a lot of development going on anywhere else, but then, I probably don't know all the products that you consider to be competing, or whether they're working nearly as hard as you do in producing new tools).

BTW, a few tools that are quite commonly used, and so it might make sense to go for those sooner rather than later might be DBE, ACDNR, StarMask and MT (to name as few as possible   .

Of course, I would too include the tools involved in calibration, registration and integration... Not a wish list, just my very personal feedback if there is such thing as a priority list as far as what will get documented first. I'd say NoiseGenerator can wait a bit

[Enzo De Bernardini]

Wow! Impressive!

A little issue: JPG images are not displayed in doc browser (but are ok in external browser, like FF). Win XP 32b.

Best regards,

Enzo.

[zvrastil]

A little issue: JPG images are not displayed in doc browser (but are ok in external browser, like FF). Win XP 32b.

Same system, same problem. IE version 8.0.6001.18702

[oldwexi]

Hi Juan!
Thanks fore the documentation extension.
I was was afraid that development will stop for this.

To click the counter also in the other direction,
as a customer i prefer development over paperwork:

 
Gerald

[sigurd]

FWIW Juan,

The DynamicPSF documentation is a paragon for how documentation for technical software of this type ought be written, and so rarely is. In contradistinction to some competing software with copious documentation; this is actually useful.

I'm not interested in the recent "controversy" surrounding documentation. With that said, I think this kind of documentation is exactly the kind that befits the level of sophistication and precision I've come to expect from you and your team.

Thanks so much. Keep up the excellent work.
-erik

[jtheios]

The DynamicPSF documentation is a paragon for how documentation for technical software of this type ought be written, and so rarely is. In contradistinction to some competing software with copious documentation; this is actually useful.

... I think this kind of documentation is exactly the kind that befits the level of sophistication and precision I've come to expect from you and your team.

I completely agree with Erik's comments. The DynamicPSF documentation is first rate, and will be very helpful. Until that tool was released I had very little success with Deconvolution, and the documentation will give me a firmer conceptual foundation. Personally, I'd like to see this same level of documentation for DBE, Deconvolution, MT, and the wavelet-based tools.

Thanks so much,

John

[RBA]

Personally, I'd like to see this same level of documentation for ...

If you see the documentation already written for other processes such as HistograhTransformation, ColorCalibration, Curves, etc. I think it's clear that the "level" of documentation you saw for DynamicPSF is the "standard" level for PixInsight's official documentation, and not an exception.

[marekc]

I'd like to add my voice to the chorus of approval for this documentation!

I agree that the documentation is well-written, with Dynamic PSF being a great example, as others have noted. I also agree that writing high-quality documentation like this is exactly the right thing to do at this time. As Georg noted, it will probably do *more* to help PI's position in the market than new modules would. I think Georg is absolutely right about that.

It must be a ton of work to write this documentation, but I think it's well worth it. Now I feel like I have a step-by-step guide to how to use DynamicPSF, for example, and that's great.

From my point of view, the `ultimate' documentation will be the one for StarMask. There's already a pretty detailed explanation in the NGC 5189 Processing Example, but I'm looking forward to an even better guide in the Reference Documentation! I think that star masking is the most difficult mountain to climb in PI. It is a real `gateway' to getting the most out of the software. RBA's recent tutorial is really helpful, but when it comes to something like StarMask, the more explanations, the better!

Deciding what level to `pitch' the documentation must be tricky. In a perfect world, I'd love to see a book about PI that's analogous to Scott Ireland's `Photoshop Astronomy' book, or Berry and Burnell's `Handbook' (which relates to their AIP4WIN). Those books do a great job of talking to someone who doesn't know much about the basics of imaging. It's probably not realistic to imagine that the PI documentation can be pitched at *that* basic of a level... that would take a long time to write, and PI users can buy those books just like PS users can. But, just as a suggestion, I'd say that it's worth looking at books like those from time to time, just as a reminder of `things that new users might not know'.

But, having said that, I think this new documentation is great, and I'm really looking forward to more! Thanks!

- Marek

[RBA]

To me, the issue with star masks is that, first, depending on why you want/need the star mask, it will need to be built differently, and second, this also needs to be tailored to the image you're working with.

That's why "cooking recipes" for star masks often fail. Ideally I think that the best thing to do here would be to understand what type of masks you need for specific scenarios and images, and then of course knowing how to adjust the parameters to obtain star masks with the appropriate profile.

I'm writing some stuff about that, which will eventually see the light, but it's all specific to the type of data I usually work with, that is, low resolution, short focal length images.

[marekc]

I hope I'm not taking this OT into star masks...

This weekend I'm starting to chip away at a long project: Exploring what all the parameters in StarMask do.

I've taken an image, still at the linear stage, and I'm varying all of the StarMask parameters, one at a time, by small increments. I've generated 125 star mask files so far, and I'm using the Animation script to see what each StarMask control does. I hope to one day `internalize' each animation, so that I'll know what each control does, intuitively.

After I do this with a linear image, I'll apply the AutoSTF parameters to HistoTrans, and then do it all over again with the non-linear image. I think this is the only way for me to *really* learn what all those sliders and buttons do.