Please beware of the following website and individual

[admin]

EDIT 2020-01: As of 2020 this advice is still current, though - thankfully - it appears many in the AP community are now aware and are similarly warning community members.
EDIT 2020-06: It appears Roger is now, for the first time, "attacking" StarTools specifically (we're honored!) by - we're not making this up - criticizing how this light-pollution filtered image (thus missing chunks of the visual spectrum) is not showing "correct colors". It speaks volumes on his tenuous grasp of the subject and why he and his "advice" is shunned by the AP community.

Hi,

The more advanced StarTools or PixInsight users have a deeper understanding of some of the best practices and mathematics behind the things we do - these user come well prepared and can see fluff, incorrect assumptions, mathematics and methods for what they are; a waste of time. However the same is unfortunately often not true for people new to the hobby.

Now that most Astrophotography is conducted in the digital domain, processing and development comes down to digital signal processing. The latter is a complex area, where getting your methods and mathematics right is paramount. As you all know, StarTools tries to abstract this away from the user in the interest of accessibility, but also tries to leave the door open for deeper tweaking in the hope that people want to learn more. However - make no mistake about it - at the end of the day StarTools needs to adhere to mathematical truths and rules that physics dictate. Note that StarTools is - intentionally - less strict here than for example PixInsight; some modules can be 'abused' to augment and modify data in ways that are 'plausible', yet not necessarily perfectly/scientifically describe what has been recorded. The rationale is that it is better to reward people that are just starting out and have limited data collection capabilities (or experience) with an image that enthuses them to stick with the hobby and maybe take the next step, rather than shutting them out. However, the focus should always remain on improving one's understanding of data acquisition and processing, in order to advance and improve.

It is with great regret then that some time ago, I found Roger Clark's "clarkvision.com" website and "articles" on processing. Virtually all these articles on processing, completely do away with best practices, giving way to pseudo science, logical fallacies (oh the logical fallacies!) and mathematical faux pas.

The "articles" exhibit a litany of errors, nonsense and misunderstandings of how some basic algorithms and mathematical concepts work in image processing, including (but sadly not limited to) light pollution removal, deconvolution, the commutative property in mathematics, stacking, linearity vs non-linearity of data, basic physics and color theory.

I politely inquired why he thought any of this was good practice or scientifically accurate and got nowhere, even after demonstrating the mathematics and writing code to disprove some of his more fanciful claims and pointing out errors and untruths. The fact that I'm having to put this warning up, gives you an indication that effort didn't go very well.

Without going into the subject matter too deeply right now, I just wish to warn you and the AP community at large to - at the very least - research with a very critical mind any of his claims and/or advice should you happen to come upon it on Reddit, DPReview or elsewhere.

If you have any questions about his "articles" or claims, I'm happy to address them.

Wishing you all clear skies and minds,

[ChrisLX200]

By coincidence I also had a run-in with him on DPReview where he's spouting his rubbish to all and sundry (and taking in quite a few newbies). I had cause to go look at his website and was not impressed, either by his 'theories', statements of fact, nor (in particular) his practical results. He was saying that by using his methods then a DSLR would out-perform a mono CCD camera, and so many other stupid things about the efficiency of DSLR sensors that I just told him to go have a nice day and dropped him. He wasn't worth debating with - he exhibits an inpenetrable bias with an almost religious conviction in his own ideas. Sadly arguments are still going on and folk are thanking him for his information... Sometimes you just have to learn the hard way, but thanks for the heads-up Ivo and hopefully some will avoid his brain-washing!

ChrisH

[admin]

taking in quite a few newbies

folk are thanking him for his information...

And that's the infuriating part; you and I know better, but he is doing a lot of damage, undoubtedly causing people to give up on the hobby in the long run, or at the very least setting them back months and years in their development.

Trust me when I say that you and me aren't the only ones who this has come to their attention to - there is a growing number of people in the AP community that are similarly concerned.

Roger scores very high on John Baez' Crackpot Index, scoring 20 points right off the bat for naming something after himself; ("The Clark Exposure Factor" a new unit of measure he's "invented"). Normally these things self-implode and go away, but this appears to be a much more serious runaway case - particularly due to the link spam to his site; at one stage every other of his posts would contain a link.

[ChrisLX200]

Yes, I noticed all the links to 'Clarkvision' but I didn't stay too long after following one...

Chris

[Cheman]

Roger scores very high on John Baez' Crackpot Index,

When I first read this I thought it said JOAN Baez crackpot index!!?? thereby hinting at my age
Che

[admin]

Roger scores very high on John Baez' Crackpot Index,

When I first read this I thought it said JOAN Baez crackpot index!!?? thereby hinting at my age
Che

If only she knew about the crimes perpetrated against newbies by this man, I'm sure she'd be writing a protest song right now!

[ChrisLX200]

I just got threatened with libel by him... LOL! Jon Rista is having a tough time trying to get through to him but I admire his persistance.
http://www.dpreview.com/forums/thread/3946947?page=4

ChrisH

[admin]

I just got threatened with libel by him... LOL! Jon Rista is having a tough time trying to get through to him but I admire his persistance.
http://www.dpreview.com/forums/thread/3946947?page=4

ChrisH

Honestly, I've stopped engaging with him directly out of respect, as I suspect something more sinister is at play - a condition which I don't wish upon anyone. I don't know what he was like a few years ago as a person, but I cannot believe anyone could be so irrational and abrasive and at the same time be able to function in a team or hold a job where scientific and mathematical rigour are paramount.

Having a spirited discussion is one thing - it can be quite healthy and furthers understanding of both participants and observers. But denying simple facts is just downright bizarre. I don't want to see this thread devolve into along whinge or b***h-fest, as that is improper behavior, unconstructive and not the purpose of this forum. I will just give a small example of how I've spent many, many hours trying to teach(?) him a basic fact, to no avail.

As we all know, RAW converters such as DCRAW, by default and unless you specifically turn this off, perform a stretch in order to convert the linear data (e.g. photon count) into something that matches the non-linear response of the various rendering devices (e.g. a screen). Again, we all know this. Roger does not that dispute that.

However, for reasons unknown, Roger does dispute that the typical stretch (aka non-linear transformation function) conforms to the BT.709 or sRGB standards, because that's what our devices are based on and require. It's fine if you want to debate something. It's not fine (or rational) if you deny 3rd party sources such as the actual DCRAW manual, help text, source code and black box behaviour, along with a myriad of other sources that confirm that, yes, the standard non-linear transformation function to make linear data non-linear, is encapsulated in the BT.709 or sRGB standards (there are some other profiles as well).

From the DCRAW manual;

Code: Select all

"-g power toe_slope
Set the gamma curve,** by default BT.709 (-g 2.222 4.5)**. If you prefer sRGB gamma, use -g 2.4 12.92. For a simple power curve, set the toe slope to zero."

From the Wikipedia on the sRGB standard;

Code: Select all

"LCDs, digital cameras, printers, and scanners all follow the sRGB standard."

In a last ditch effort to convince him that David Coffin (the author of DCRAW) is not a liar, and that the many different sources on sRGB and BT.709 are not part of a conspiracy, I even wrote some publicly available software with full source code to analyse DCRAW's behaviour as if it were a black box; reverse engineering the modification of each brightness level of DCRAW's input vs the output and plotting the result. It comes as no surprise to anyone that the curve thus plotted exactly matches the BT.709 transformation curve.

My thanks for all this effort? I'm now an "Internet Troll" in one of his "articles".

The reason why we were "discussing" non-linear transformation curves in the first place? His attempt to derail a discussion about his mathematically incorrect insistence that it's perfectly ok to perform linear operations (such as light pollution subtraction and deconvolution) on non-linear data, "because you can't see the difference".

Just like you "can't" see the difference if you take this linear image;

nonlintest.png (1.35 KiB) Viewed 63539 times

Add some light pollution (RGB 32, 0, 0);

nonlintest_lp.png (1.93 KiB) Viewed 63539 times

Stretch the image (I used a gamma 2.2 which, for all intents and purposes yields the same as a sRGB conversion)

lpexamplew.png (2 KiB) Viewed 45740 times

And try to use his "method" of then moving the black point to subtract the light pollution.

nonlintest_lp gamma22lpsubtracted.png (16.49 KiB) Viewed 63539 times

Nope. Can't see the problem here at all.

EDIT: And here is an interactive graph for peer-review that I built that demonstrates the math, and the difference between subtracting light pollution before and after stretching. That is, if you accept that Norman Koren (Imatest author), is not in on the conspiracy-against-Roger when he says that; "On the encoding side the "ideal" is pixel level = scene brightness ^ (encoding gamma), where encoding gamma = 1/display gamma". (note that this is the formula being used for gamma correction in the graph)

[LanFeusT]

I just realized he's /u/rnclark an admin on the Astrophotography subreddit.

Not knowing the intricacies of the math that goes behind all this, I remember reading several of his posts and thinking "nice this guy seems to know his shit".

Glad to know I will have to take that with a grain of salt moving forward! Thanks!

[admin]

I just realized he's /u/rnclark an admin on the Astrophotography subreddit.

Eek! I hope not - are you sure he's a moderator now?

Not knowing the intricacies of the math that goes behind all this, I remember reading several of his posts and thinking "nice this guy seems to know his shit".

This YouTube 4:13 explainer by MinutePhysics succinctly explains in the issue of doing processing before and after stretching.
The crux of the issue is shown at 2:10; the sequence within which you do things matters a lot!

Roger maintains it doesn't matter for things like light pollution removal, deconvolution and many other processes (and many of his other ramblings get sequence hopelessly wrong). But now you know better!