CMYG Batch deBayer Script

[Niall Saunders]

Hi all,

Welcome to my (first) little (big) PJSR script.

After weeks of procrastination, whilst I failed to find time to polish out the last little blemishes on this script, I feel that I should just publish it here and let others decide whether the script is of any real use.

Fundamentally, the script was written to allow me to determine how well 'other' CMYG deBayer routines work - most of which, in my experience, didn't work that well.

The second driving force behind the exercise was to allow me to get to grips with the process of writing PJSR scripts in the first place - hence the reason that this script is so big !! It has been 'fully' commented. (Well, at least it has been commented as much as I possibly could - to allow others to learn from my experience  )

It has also had, in places, input and feedback from Juan - in areas where I could not see the PJST solution, or in areas where I was making fundamental PJSR mistakes.

The script does work, and does seem to work quite well for my (amateur-level) data acquisition. Obviously, I have only used it with the Meade DSI-IIC camera, and primarily only with RAW subs obtained from Meade's proprietary 'Envisage' software. However, I have now started using Craig Stark's 'Nebulosity', and will make code adjustments as I discover them.

I certainly hope that someone can at least try out the routine - I would like Juan to be able to include the script with some future release of PI - simply because of the exhaustive commenting. I know that, had I found more comments when I was trying to learn, life would have been somewhat easier !!

Cheers,

[Niall Saunders]

Hi all,

Thanks to Georg, a minor 'bug' has been spotted at line 3106

I have used

Code: [Select]

console.show
where the code should have been

Code: [Select]

console.show ();
(The emphasis being the missing () and the lack of the statement terminating ;
either of which ought to have thrown some sort of error.


Interestingly though, the erroneous statement compiles and runs quite happily (thus demonstrating that syntax checking is not rigourous in PJSR, so you really do have to be careful as a programmer, and make sure that 'silly' mistakes do NOT slip through the net  ).

Cheers,

[Juan Conejero]

Hi Niall,

Thank you for a brilliant work.

This script is excellent in both design and implementation, and the source code is so well documented that it will serve as a reference work for many developers. Very well done!

I am glad and very happy to include this script in standard PI distributions from now on.

Interestingly though, the erroneous statement compiles and runs quite happily

Indeed. This is a "characteristic" of JavaScript, but I fully agree that this sentence should have generated at least a compilation warning. But things are more complex though.

Since there exists a show method of the global console object, the compiler interprets the sentence:

Code: [Select]

console.show;
as composed by a single valid expression, whose value is a Function object. For example, you could legally write:

Code: [Select]

var myFunc = console.show;
and hence:

Code: [Select]

var myFunc = console.show;
myFunc();
which in turn resolves as a call to:

Code: [Select]

console.show();
The problem is that the JavaScript compiler does not warn us about an unused expression here. In fact, this reference to a method could have some collateral effect --which doesn't exist in this case, but the compiler has no way to know that--, so the fact that this sentence is really an unused one cannot be guaranteed, and hence the absence of a warning is somewhat justifiable.

As for lacking ; punctuators, JavaScript is permissive by design, which was IMO a very unfortunate ECMA decision. Fortunately, the next ECMAScript 5 standard solves this and many other language issues.

[Niall Saunders]

Hi Juan,

And thanks for the compliment.

I am happy to formally authorise you to include the script in all future releases of PI, and only request that the first 26 lines, and line 61 remain fundamentally unchanged. Obviously, you are free to 'polish' up the script to suit your normal release methodology.

I have rectified the 'console.show();' bug in the v1.5 release, and have now added a 'history' segment to indicate version changes.

Cheers,