I observe quite rarely, but here's my advice: once you max out with the 'scope (& double-stacking options), I strongly recommend getting a binoviewer. I have a Baader Maxbright with 2x 15 mm Plössls (just regular ones) and the views with the 50 mm and 90 mm H-alpha setups are wonderful. I also had j...

I use helioviewer.org, which shows the current SDO images among others.

To those who downloaded the Ubuntu package: I've uploaded a corrected one, which also installs an ImPPG application shortcut (so it can be selected in "application launcher" of your desktop environment). The same goes for building under any Linux (or alike) system. Pull the latest source code, and t...

I'd miss out the wavelets and go straight to ImPPG for sharpening Indeed! It will work best with raw, unprocessed stacks. Though one could do the primary sharpening elsewhere (e.g. wavelets in Registax) and then just touch up in ImPPG (probably with L-R disabled, just apply unsharp mask and modify ...

Hi Rainer,

That's right, ImPPG is for post-processing of stacks. So you must stack your AVI first (e.g. in AutoStakkert), and then you can open the resulting TIFF in ImPPG. On the home page you'll find links to a few tutorials:

http://greatattractor.github.io/imppg/

GPU mode will be activated by default when you first start ImPPG 0.6.0. The current mode is indicated in the status bar in the lower right:
You can switch between CPU/GPU modes in the menu:

Wow, great to hear this! Thanks for checking. I must get me one of those high-end babies one day...

Hmm, by the looks of it, it's not "too strong", rather the processing went completely bonkers :) Standard OpenGL has no provisions to choose the active GPU (though there are AMD- and NVidia-specific extensions, as I've now googled), it's up to the operating system/driver configuration. I wouldn't th...

Thanks for feedback, Marty. When you switch to CPU mode, does everything look OK? Also, in GPU mode please try with View/Scaling method/Linear. And check if a saved output image also looks bad. I tested on 3 different GPUs (Intel, NVidia, AMD), each under Linux and Windows, but yeah, there might be ...

Hard to compare GPU-CPU performance, I'd need many data points. As for a desirable GPU, even my ancient Intel HD Graphics 5500 (integrated) benefits here; generally, the more powerful, the better. I'm wondering if the current highest-end GPUs could apply L-R in real-time for, say, a 1 Mpix image (if...

ImPPG version 0.6.0 has been released . After some architectural cleanup, I added a GPU/OpenGL back end, that is, almost all processing (except image alignment) is now performed on the GPU. In practical terms, on most computers it means: processing is faster by a factor of several or more for quite ...

ImPPG version 0.6.0 is available at: https://github.com/GreatAttractor/imppg/releases New features: GPU (OpenGL) back end for much faster processing Enhancements: View scrolling by dragging with the right mouse button (previously: with the middle button) Zooming in/out with the mouse wheel (previous...

Good job, Jochen! To tease the max resolution out of these 50 mm, I suggest you make a 2x2 mosaic. I have similar pixel pitch (3.75 µm) to yours, and such mosaics work very well for me with a 2x Barlow's lens element screwed directly into camera's nosepiece (giving ~1.6x), e.g.: https://astrob.in/22...

And I still use AviStack 2 (for those cases where Stackistry fails). Seems OK on prominences too.

Then how do we calculate the rise in temperature along the converging beam of our OTA? There's certainly some of that, but probably less important than one would think. The air (over the kind of distances we have in telescopes) is after all quite transparent to solar radiation. Consider this: Lunt ...

Here's the mistake: 1 m² = 100 cm × 100 cm = 10 000 cm². Assuming irradiance of 1000 W/m² (0.1 W/cm²), a 15 cm-diameter objective gathers only π × 7.5² cm² × 0.1 W ≈ 17.7 W.

(Or in other words: if the unfocused irradiance is 1000 W/m², you can't have a mere 15-cm lens gather > 3 kW ).

JochenM wrote: ↑

Wed Dec 11, 2019 4:32 am

I have the Moonlite CM-Mini fitted instead. I'm guessing that pretty much covers that?

Yup. This just leaves pointing the telescope possibly a bit sideways and finding the best camera position/orientation.

Hello Jochem, welcome to Solarchat! I can see two (not very serious) issues in your image: - drooping focuser (most likely); the on-band FOV area ("sweet spot") should be more or less central, but you have it shifted downwards; you can read about it here: https://solarchatforum.com/viewtopic.php?t=1...

Hello Salvo, enjoy the forum!

Roel80 wrote: ↑

Sat Nov 23, 2019 12:02 pm

That 140mm is measured from the focal plane to which part of the etalon unit?

I suggest you measure it precisely yourself. Here's a simple method I used: viewtopic.php?f=9&t=19238

And here's a successful build of the LOWSPEC spectroscope (in Polish): https://astropolis.pl/topic/68522-wydru ... ektroskop/
First light: https://astropolis.pl/topic/69238-widmo ... o%C5%9Bci/

With a small (2-year) delay, I've finally added a description of algorithms used by Stackistry/libskry (an open-source cross-platform stacker):

link to PDF

Thanks, Bart, glad you like it.

As for your setup - this is with a PST etalon, correct? So the Intes can manage the required 200 mm backfocus, or is it some other approach?

Great result, the high resolution is immediately noticeable.

I wrote the FlyCapture (i.e. "native" PGR) and IIDC drivers for PlanetaryImager (IIDC a.k.a. DC1394 is a universal protocol supported by all PGR's USB cameras). Marco (PlanetaryImager's author) does publish macOS builds (.dmg files) in the Downloads section, but likely they do not have FlyCapture su...