[Closed] user's manual

Some of the comments here are insulting to say the least. How dare someone suggest for users to buy a manual after purchase of an item. You must be kidding yourself. I don't know how you make your own money. I work hard for mine.

If you want to buy a manual, that's your cup of tea. It doesn't make right the fact that there should be a users' manual for a relatively expensive piece of software.

Most times, third party softwares are even to compliment the developer's. For goodness sake, the developer has no manual.

There are tons of freeware on the internet with manuals. I have bought stuffs for $1 that came with manuals. Who is even asking for a comprehensive manual? Why not at least present something.

Anyone who is trying to deflect this unfortunate situation by suggesting a third party manual should be ashamed of themselves . Anyone suggesting that the developer has not time for manuals should also be ashamed on themselves.

Perhaps the developer doesn't even know what the software does for any particular effect. All what I see in third party tutorial is suggestions of trial and error.

This crass disregard of customers is just unconscionable. It is a good thing that I paid for just one year licence. Once it expires, I am moving on to other programs and unsubscribing from reading all these BS . I don't care how good APP is, the insult is enough. There are other equally good softwares. Some of them are even for free.

Have a good day everyone.

Posted by: @stuartt

@markabbott - Hi Mark. I hear you. A manual would be nice, but it's not essential. I am a total beginner at astrophotography, but I bought APP last week and find it super easy to use. You can just load up all your lights and calib frames and use the default settings and get a nice result. Sure at some point, I'd like to learn how to fiddle with all the dials and do some fine tuning, but I think Mabula has set it up so it works really nicely 'out of the box'

I would argue against the concept “a manual is not essential.” Some of the settings aren’t too difficult to figure out, but the settings on some have very subtle differences which may not be readily apparent. Also, sometimes it seems as though a setting has one effect but on a deeper level, it does something completely different which is not obvious.

A manual is essential.

Hi all @meadeuser, @tgiann3, @dancia12, @oopfan, @devonshire, @binfield, @markabbott, @tpmpohung, @stuartt, @vincent-mod, @jalabrecque, @karolbe, @leolibbey,

I have read all remarks, suggestions, ideas, feedback about a user's manual for Astro Pixel Processor from the last few days.

Let me first thank you all for joining in this topic. I appreciate all comments about this, both the positive and the negative. I really understand the frustration that I have caused about this, because I am fully aware that I have over-promised about the manual in the past... so I really want to give you all a sincere apology about not having released it yet.

As stated before, we will definitely release a full printable documentation alongside APP. That intention is still there and I am frustrated myself about not having published it yet... Personally, I fully agree that APP should have a complete manual included.

I have discussed the situation with Vincent @vincent-mod and Wouter @wvreeven and we sincerely want to commit to the following:

• We will focus on releasing APP 1.083 stable in the coming days and weeks.
• Then after it's release, I will start releasing the documentation as I have it now and I will add to that each week going forward so it will soon grow to a complete and comprehensive fully printable documentation in PDF format with illustrations and references.

Please accept my apologies for not having released it yet, I feel bad about this myself and I fully understand any frustration that I might have caused about this.

Kind regards,

Mabula

Thank you Mabula for addressing this issue and for the update.  I’m very pleased with APP but the lack of manual has been frustrating.  

Im looking forward to the 1.083 release and will begin reading the documentation as soon as you release them

i appreciate that you are working to address our concerns

Thanks, this is what we wanted and needed to hear…and appreciate you finally answering our concerns…👍🏼

Posted by: @mabula-admin

Hi all @meadeuser, @tgiann3, @dancia12, @oopfan, @devonshire, @binfield, @markabbott, @tpmpohung, @stuartt, @vincent-mod, @jalabrecque, @karolbe, @leolibbey,

I have read all remarks, suggestions, ideas, feedback about a user's manual for Astro Pixel Processor from the last few days.

Let me first thank you all for joining in this topic. I appreciate all comments about this, both the positive and the negative. I really understand the frustration that I have caused about this, because I am fully aware that I have over-promised about the manual in the past... so I really want to give you all a sincere apology about not having released it yet.

As stated before, we will definitely release a full printable documentation alongside APP. That intention is still there and I am frustrated myself about not having published it yet... Personally, I fully agree that APP should have a complete manual included.

I have discussed the situation with Vincent @vincent-mod and Wouter @wvreeven and we sincerely want to commit to the following:

• We will focus on releasing APP 1.083 stable in the coming days and weeks.
• Then after it's release, I will start releasing the documentation as I have it now and I will add to that each week going forward so it will soon grow to a complete and comprehensive fully printable documentation in PDF format with illustrations and references.

 

Please accept my apologies for not having released it yet, I feel bad about this myself and I fully understand any frustration that I might have caused about this.

Kind regards,

Mabula

 

 

 

Thank you Mabula for addressing this issue. I would encourage you to delegate the creation, enhancement, and upkeep of the documentation if needed. There are only so many hours in the day. 

Having been a software developer, QA engineer, and written hundreds if not thousands of pages of documentation, I am sympathetic to a small company with high goals.  Writing and editing well is extremely time consuming.  Particularly in a non-native language.

My suggestion is that the APP tech team produce rough draft quality chapters in some common form (.docx?) and release them to a somewhat screened volunteer team for editing.  That would save significant time.  The first draft edited version would then go back to the technical team for review, comments, and a decision could be made as to who would create the second edited draft.  That should be releaseable, even if not in final form.

Of course some of the volunteer work would likely be unacceptable, but we are adults and should be able to take that small rejection offered with some appreciation!

Steve

Thank you Mabula,

As a BRAND NEW user to this software (and quite dumb) I would welcome some kind of user manual. I was referred to this APP software because of my frustration tring to use other stuff out there with not much success. This would be a joy to work with if I could at least have a place to look for problems I run into or even a good description of what each function does and/or how it should be used with recommended settings.

Dale

@scpanish

Sounds like you're volunteering, Steven. 😀 

Actually, I am too. I am also a software engineer with a lot of writing experience (ad copywriting for several years, software docs, wrote and edited for Software Development magazine) and I would be delighted to help. Charlie Bracken's quick start guide would be a candidate for inclusion if he's willing.

The Bracken quick start guide?  Probably best kept at arms length from anything done here.

If you check out his (Bracken's) blog posts on the Deep Sky Imaging Primer, at the end, you'll find an April 2021 post that says he's working on a Third Edition, targeting a Fall release, and both Affinity and APP are mentioned.  

If it comes to pass, 3rd party coverage of APP (quite apart from any product doc), would be a very good thing.  

Posted by: @scpanish

Having been a software developer, QA engineer, and written hundreds if not thousands of pages of documentation, I am sympathetic to a small company with high goals.  Writing and editing well is extremely time consuming.  Particularly in a non-native language.

My suggestion is that the APP tech team produce rough draft quality chapters in some common form (.docx?) and release them to a somewhat screened volunteer team for editing.  That would save significant time.  The first draft edited version would then go back to the technical team for review, comments, and a decision could be made as to who would create the second edited draft.  That should be releaseable, even if not in final form.

Of course some of the volunteer work would likely be unacceptable, but we are adults and should be able to take that small rejection offered with some appreciation!

Steve

What a fabulous idea.

Sure Rick, I'd volunteer.  Might be the only way I learn the program!  But if interested the staff woudl need to issue a call for volunteers and select a few.

Steve

Sure Rick, I'd volunteer.  Might be the only way I learn the program!  But if interested the staff woudl need to issue a call for volunteers and select a few.

Steve

Hi All @scpanish, @tgiann3, @devonshire, @rickwayne, @dalepenkala, @meadeuser, @markabbott

Thank you all very much for sharing your thoughts, concerns and ideas regarding the user manual. I really appreciate your input and understanding here.

Having been a software developer, QA engineer, and written hundreds if not thousands of pages of documentation, I am sympathetic to a small company with high goals.  Writing and editing well is extremely time consuming.  Particularly in a non-native language.

My suggestion is that the APP tech team produce rough draft quality chapters in some common form (.docx?) and release them to a somewhat screened volunteer team for editing.  That would save significant time.  The first draft edited version would then go back to the technical team for review, comments, and a decision could be made as to who would create the second edited draft.  That should be releaseable, even if not in final form.

Of course some of the volunteer work would likely be unacceptable, but we are adults and should be able to take that small rejection offered with some appreciation!

Steve

Oh, once we a first good version, I can quickly make a PDF from that as well, so users can print at at home and put it on their desk. Many have requested that as well.

Posted by: @mabula-admin

Hi All @scpanish, @tgiann3, @devonshire, @rickwayne, @dalepenkala, @meadeuser, @markabbott

Thank you all very much for sharing your thoughts, concerns and ideas regarding the user manual. I really appreciate your input and understanding here.

Having been a software developer, QA engineer, and written hundreds if not thousands of pages of documentation, I am sympathetic to a small company with high goals.  Writing and editing well is extremely time consuming.  Particularly in a non-native language.

My suggestion is that the APP tech team produce rough draft quality chapters in some common form (.docx?) and release them to a somewhat screened volunteer team for editing.  That would save significant time.  The first draft edited version would then go back to the technical team for review, comments, and a decision could be made as to who would create the second edited draft.  That should be releaseable, even if not in final form.

Of course some of the volunteer work would likely be unacceptable, but we are adults and should be able to take that small rejection offered with some appreciation!

Steve

I really like your suggestion Steve, thanks a lot!

I am discussing details about this with Wouter and Vincent, but I think your suggestion has good merit. I could soon release a first rough draft for sure, then the proposed team could add to that so each part of the application and it's functions will be looked at from all angles making sure that the user manual will be extensive and detailed from all those viewpoints. In fact that is the hard thing of making good documentation probably, to make sure that all the angels are covered.

Once we have an extensive document including educational pictures, graphs etc.., we can also quickly make a simple/basic version from that.

To do this efficiently, I would propose that I setup an online wiki page with user accounts for everyone that will help and where everyone could work on at the same time. Off course we need to keep track who alters certain pieces of documentation in each revision between me/Wouter/Vincent en the team, right?

Steve, do you know a certain type of wiki or online document tool in which we could do this properly? I know that there are several types of wiki that should make this possible for sure, but your experience might make us use the best tool 😉

Oh, once we a first good version, I can quickly make a PDF from that as well, so users can print at at home and put it on their desk. Many have requested that as well.

Mabula

Thank you so much Mabula; this is very exciting.

Hi Mabula,

Having been retired for a LONG time I have not kept up with what tools are current.  Sorry!  A Wiki might work for initially setting out content but if you are already using source control that would work fine for documents too, assuming we used a common format (e.g. docx).  I've always written documentation solo, the old fashioned way, starting with engineering documentation and creating an outline and then filling in the details.  I don't know how well moving Wiki page(s)  to printable text would work - might be just fine but I've never done that.   It might be a formatting nightmare.  I just don't know.  I can ask some friends who are still working, but they are all developers with poor writing skills and would not be doing user-level docs.  I used to get stuck with it because my writing skills were good.  I mostly used Word, the Adobe tools were beyond our needs.

This is your product and I don't intend to drive!  But my inclination would be to keep this effort as simply organized as possible and get something basic out that the beginners (like me!) can really make use of ASAP.  It doesn't need to be fancy, and initially it doesn't need to be comprehensive.  It does need to cover the basics, lay out the important concepts, and be decently written and comprehensible, and it should likely be printable.  It should prioritize content over style.  

Having said all that, does anyone more current than I have some information to offer?

Steve

creating an outline and then filling in the details.

Steven,

Yes.  Same here.   I draft my Table of Contents as an outline of the topics to be covered, in the order best able to move the reader through the subject.   Then I write as needed, to populate the major and subordinate headings, and when I realize that I have a gap, or topic out of order, I fix the ToC, regenerate my headings, and go back to writing.   No reason why that technique should be tied to a particular medium, though. 

User documentation should be thought of as a training resource, so it should lay vocabulary and concepts down in an orderly fashion.   No jumping into advanced topics, before the reader has been introduced the basics.

My $0.02 is to start with reworking the Quick Start guide that already ships with APP.   I quite liked what was there, as far as it went, but it is unfinished.  Just a few pages of product vocabulary, general concepts, and navigation, enough to show a basic stack-and-stretch, with a pointer to product doc for more.  A Quick Start, not the whole enchilada.

- Bob

Agreed on that process.  My original intent was that Mabula et. al. would throw out some rough content and we volunteers would edit it and throw it back.  The quick start is a fine starting place, it is a rough outline.  I pretty much need the content provided to me for all but the basics, I've only been using APP for 2 months and I'm just starting to get reliably good results.

Steve

Mabula, I don't have a tenth of your experience with astronomy or imaging, so I would never presume to tell you how the program should work.

But  (and you all knew there was a "But" coming after that sentence!), I have been doing software development for longer than some of your customers have been alive, so please permit me to proffer a philosophical point:

Sometimes customers don't know what they want, or more precisely, you have a much better idea of  where the program should go. Asking "what should the next feature be?" does not always produce valuable results; usually the users are blinkered by their current experience and your vision might be exactly what they need, but never imagined that they wanted. My advice is never to be afraid to do that.

However, when gangs of them ask for a specific thing, that's very different. Frequently that's a pain point. In successful dev shops, pain points are like bugs: Priority 1 for development, always. In fact pain points are bugs. They're a sign that while the program may be performing to spec, the spec is wrong. The users have placed a higher value on a particular aspect of the software than you did. Not a failure, no one has a magical User-Think-O-Meter to predict what users will want, but it's a call to display agility and put resources on that problem.

It's always a process, and there's no infallible way to determine which kind of situation you're in. For my money, the user manual is the second kind, and I commend you for recognizing that.

Mabula,

I love Astro Pixel Processor!

The topic of a User Manual has been beaten to death, but I still want to add my 2 cents worth (American expression).

For the people who are brand new to astro photo processing I think the best solution is for them to buy one of the books on the subject, so they gain an understanding of what are flats, darks, bias, subframes, etc. An APP user manual is probably not going to help with this, and why reinvent the wheel?

What would be most useful is an explanation of the parameters (what is Kappa?). As Charles Bracken has stated in his "Astro Pixel Processor Quick Start Guide," in most cases the default settings work very well. However, it would be nice to know what the settings do. Yes, some of the tooltips give you the answer, but not always.

Look, for example, at Integration. There is a lot of information in the tooltip on choosing the integration method and outlier rejection. But what is kappa and how does one choose the values?

I do appreciate all the built in automation and the great results!

Ed

I tend to agree, and a users manual that gives those explanations with worked comparison examples, would also be enticing for future users and those transition away from other options.

I have managed to go by tool tips and trying various options. But I did learn too late the benefits of nearly hidden but excellent tools such as align channels in tab 2 (very powerful, but missed by most), droplet size and scale for drizzling, integration moelda for downscaling without issues (mitchell-netravali), and other choices that are less common in the very nice video tutorials.

On the other hand, I have asked some queries that were answered in the videos, but it is not easy to find like in a document.

A lot of the attraction of PI for example, is the sheer volume of user tutorials available, so while I would add to a call for a formal user manual (a technical document), perhaps some of us in the community could add more to tips and tricks and tutorials like PI users and broaden the appeal especially to intermediate and advanced users too.

Best wishes, Col

Posted by: @ejp2012

Mabula,

I love Astro Pixel Processor!

The topic of a User Manual has been beaten to death, but I still want to add my 2 cents worth (American expression).

For the people who are brand new to astro photo processing I think the best solution is for them to buy one of the books on the subject, so they gain an understanding of what are flats, darks, bias, subframes, etc. An APP user manual is probably not going to help with this, and why reinvent the wheel?

What would be most useful is an explanation of the parameters (what is Kappa?). As Charles Bracken has stated in his "Astro Pixel Processor Quick Start Guide," in most cases the default settings work very well. However, it would be nice to know what the settings do. Yes, some of the tooltips give you the answer, but not always.

Look, for example, at Integration. There is a lot of information in the tooltip on choosing the integration method and outlier rejection. But what is kappa and how does one choose the values?

I do appreciate all the built in automation and the great results!

Ed

I have been following this thread and found this post particularly interesting. I was not aware there is a book for sale. I am aware, and own a copy of the manual for PI, solely in the hopes that it might help with APP. I did not find it particularly useful as I do not yet own PI software. I have also read Digital SLR Photography by Michael Covington. I found that book generally well written and informative but I did not see a section which deals with modern Astro Image Processing. I do agree that part of the issue is learning what things like Kappa mean. But I feel that is best explained either in a book or user manual directly related to the software being used. 

if anyone has book suggestions, I would be very happy to hear your recommendations.

Mabula I have to also confess that I love APP as well! So much so that I bought it 1/2 way thru my 30 day trial!

It has taken my imaging to the next level. At least in my eyes anyway.

Yes I would love to see a manual but I also understand the amount of work it will take. I see several have volunteered to help so cudo’s to them!

I wasn’t aware of a QuickStart guide (Charles Bracken has stated in his "Astro Pixel Processor Quick Start Guide," ) I will be looking to find this guide!

Thanks again for all your work to help someone like me enjoy this hobby better!

Dale

Posted by: @dalepenkala

Mabula I have to also confess that I love APP as well! So much so that I bought it 1/2 way thru my 30 day trial!

It has taken my imaging to the next level. At least in my eyes anyway.

Yes I would love to see a manual but I also understand the amount of work it will take. I see several have volunteered to help so cudo’s to them!

I wasn’t aware of a QuickStart guide (Charles Bracken has stated in his "Astro Pixel Processor Quick Start Guide," ) I will be looking to find this guide!

 

Thanks again for all your work to help someone like me enjoy this hobby better!

 

Dale

I found that guide to be helpful in what it covers. but as it got to the details one will really need to know, I think it digressed into “to be continued.” Something is certainly better than nothing, but in what I have found in both literature and online videos there are large gaps which are difficult for a beginner or advanced beginner to fill. 

@tgiann3

Dale, there are some excellent books on astrophotography.

The most comprehensive and detailed one is "Astrophotography" by Thierry Legault.

There is also "The Astrophotography Manual" by Chris Woodhouse, and "Astrophotography on the go" by Joseph Ashley.

All of these books were published before 2017, so NONE of them mentions APP. But they will give you a foundation on processing - but be aware that a large part of each of these books deal with taking the photos (location, equipment, techniques, etc.); they are not exclusively focused on processing.

There is also "Astrophotography is Easy" by Gregory Redfern, published in 2020, but it is too elementary. It does not mention darks, flats and bias frames.

Finally, I think that "kappa" is nomenclature used by Mabula in APP, but not a general astrophoto processing term.

Kappa is used in PI as well I believe. It's a very standard cut-off or range term in statistics.

Yes, I suspect most of the parameters and algorithms are pretty standard image processing techniques and there is a well-developed (academic) literature for that.   Including astronomical image processing.  Those books cost a small fortune.  I've never seen an overview of those techniques in the amateur-oriented astrophotography books but if one has such a summary I'll buy it!  It requires an existing background in statistics.  This is a case where Mabula doubtless knows this stuff cold, but it would be difficult and expensive to look up all the algorithms.  Not so long to write a summary if I (or most any developer) had the information.

Yes, true, so Mabula and likely others will work on a manual that very likely will have this information as well.

@vincent-mod

Kappa might very well be a statistics cut off range term, but we should not need to know this.

Also, for example, in Cosmetic Correction APP uses the term "Hot Kappa" for rejection of hot pixels, while PixInsight uses the term "Hot Sigma." Alas, there is no tool tip for this item in APP, so hard to know if it is the same as in PixInsight, as you implied.

I agree, I will definitely not buy the programm without a manual.