Astro Pixel Processor

    KeesScherer replied to the topic APP weergave op 4K in the forum Astro Pixel Processor
    APP 1.068 aan het werk. Nog steeds een vergrootglas nodig (Linux Mint 18.3 Cinnamon op Hi-DPI 4K scherm met interface scaling op double)app1068
    Arsenault posted an update in the group Astro Pixel Processor
    Having tested APP ( astropixel) a few times , it seem it has good potential for Processing RGB and SHO sub frames. it takes a bit of getting used to at first and not all the things i have tried are working yet. i will need to watch more Vimeo videos, but if this works out for me i might make some Youtube videos for myself and others on OSC ( one shot color ) CCD and some NB SHO. SO far so good with this new program here in Canada. IM a PIxinsight user so it s a bit easier to get around APP software. Only using trial right now , will se how it goes. Here is first attempt at SHO with APP . RGB combinations. SHO_2_combine-RGB-image5-SC
    Alle programmaś werken prima op mijn nieuwe monster van een laptop maar APP wil nog niet lekker meeschalen op het 3840x2160 scherm en nu heb ik een extra leesbril nodig voor APP.....(NVidia GTX 1060 met driver 396.24.02). Alle andere programmaś doen dit wel goed. OS ; Linux Mint 18.3 Cinnamon. APP versie 1.062. Ik zal dit ook posten op het APP forum, maar heeft iemand hier tips?APP-4K
    Van den Broek replied to the topic APP 1.061 released! in the forum Astro Pixel Processor
    Full auto re-process van M101 data, 200 bias, 200 flats 75 darks en de 4 filter lights in 1 keer gegeven aan APP ...M101APP-lpc-cbg-crop
    Ik kwam toevallig deze introductie van APP in het Sky At Night magazine tegen. Veel plezier met lezen!IMG_0311IMG_0312IMG_0313
    Ik kwam toevallig deze introductie van APP in het Sky At Night magazine tegen. Veel plezier met lezen!IMG_0311IMG_0312IMG_0313
    Ik kwam toevallig deze introductie van APP in het Sky At Night magazine tegen. Veel plezier met lezen!IMG_0311IMG_0312IMG_0313
    Astro Pixel Processor 1.055 is released ! Big upgrade, so please upgrade and check all details at: https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-1-055-ready-for-download/ Highlights of update: - big integrration speed increase for users which integrate on conventional (non-SSD) harddrives. Speed on SSD is also improved. - Added camera support for latest Canon models EOS 5Ds, EOS 5Ds R and EOS 5D Mark IV (Dual-Pixel Raw support). - improvements for the Bad Pixel Map - improvements in star analysis and registration modules - improved star color calibration module - improved auto DDP stretch for astroscapes Be aware: Trial users can upgrade as well within their trial license period. M51-calibratedM51-uncalibrated5DsR-support
    Astro Pixel Processor 1.055 is released ! Big upgrade, so please upgrade and check all details at: https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-1-055-ready-for-download/ Highlights of update: - big integrration speed increase for users which integrate on conventional (non-SSD) harddrives. Speed on SSD is also improved. - Added camera support for latest Canon models EOS 5Ds, EOS 5Ds R and EOS 5D Mark IV (Dual-Pixel Raw support). - improvements for the Bad Pixel Map - improvements in star analysis and registration modules - improved star color calibration module - improved auto DDP stretch for astroscapes Be aware: Trial users can upgrade as well within their trial license period. M51-calibratedM51-uncalibrated5DsR-support
    Astro Pixel Processor 1.055 is released ! Big upgrade, so please upgrade and check all details at: https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-1-055-ready-for-download/ Highlights of update: - big integrration speed increase for users which integrate on conventional (non-SSD) harddrives. Speed on SSD is also improved. - Added camera support for latest Canon models EOS 5Ds, EOS 5Ds R and EOS 5D Mark IV (Dual-Pixel Raw support). - improvements for the Bad Pixel Map - improvements in star analysis and registration modules - improved star color calibration module - improved auto DDP stretch for astroscapes Be aware: Trial users can upgrade as well within their trial license period. M51-calibratedM51-uncalibrated5DsR-support
    Haverkamp replied to the topic calibratie en integratie in the forum Astro Pixel Processor
    Het is belangrijk om het volgende in het achterhoofd te houden bij calibratie van je data: Afhankelijk van de sensor, zijn er meerdere wegen naar Rome: Als je een sensor hebt met duidelijke patronen in de dark current, zoals @ed-defesche, dan wil je zowel de lights als de flats met darks calibreren. Geen bias gebruiken en ook geen bias aftrekken van de darks, want dan krijg je ook problemen in de dark current calibratie. Als je darks gebruikt, gewoon geen bias gebruiken, dat is altijd subtoptimaal en je stelt je calibratie open voor fouten. Altijd een BPM gebruiken, welk calibratie pad je ook volgt voor lights dan wel flats. Heb je een sensor met geen duidelijke patronen in de dark current en geen duidelijke amp-glow. Dan is het interessant om darks achterwege te laten en enkel te calibreren met bias, bpm voor flats en bias, bpm flats voor de lights. Hoe weet je of je dark calirbatie moet toepassen vanwege duidelijke dark current en/of amp-glow: Maak een masterbias uit een N-tal bias frames en een masterdark uit een gelijk aantal darks waar je geen masterbias aftrekt. Vergelijk de 2 met een even sterke stretch, zie je andere patronen in de master dark dan in de masterbias, zoals andere horizontale/verticale strepen of een verschijnende amp-glow dan wil je dark calibratie toepassen. Een voorbeeld van Ed: de master bias en de masterdark beiden gelijk gestretcht, in de masterdark verschijnen opeens strepen die je in de masterbias niet ziet. Dus dark calibratie wordt hierdoor bijna een must, met heel aggresieve dithering (20-40 pixels) en veel opnames kan je het mogelijk bij bias laten, maar anders niet. Het calibratie filmpje van Sara Wager is een voorbeeld waarin bias calibratie voldoende is, daarom laat Sara de darks achterwege.APP-ED-MB-strongStretchAPP-ED-MD-strongStretch
    Haverkamp replied to the topic calibratie en integratie in the forum Astro Pixel Processor
    Het is belangrijk om het volgende in het achterhoofd te houden bij calibratie van je data: Afhankelijk van de sensor, zijn er meerdere wegen naar Rome: Als je een sensor hebt met duidelijke patronen in de dark current, zoals @ed-defesche, dan wil je zowel de lights als de flats met darks calibreren. Geen bias gebruiken en ook geen bias aftrekken van de darks, want dan krijg je ook problemen in de dark current calibratie. Als je darks gebruikt, gewoon geen bias gebruiken, dat is altijd subtoptimaal en je stelt je calibratie open voor fouten. Altijd een BPM gebruiken, welk calibratie pad je ook volgt voor lights dan wel flats. Heb je een sensor met geen duidelijke patronen in de dark current en geen duidelijke amp-glow. Dan is het interessant om darks achterwege te laten en enkel te calibreren met bias, bpm voor flats en bias, bpm flats voor de lights. Hoe weet je of je dark calirbatie moet toepassen vanwege duidelijke dark current en/of amp-glow: Maak een masterbias uit een N-tal bias frames en een masterdark uit een gelijk aantal darks waar je geen masterbias aftrekt. Vergelijk de 2 met een even sterke stretch, zie je andere patronen in de master dark dan in de masterbias, zoals andere horizontale/verticale strepen of een verschijnende amp-glow dan wil je dark calibratie toepassen. Een voorbeeld van Ed: de master bias en de masterdark beiden gelijk gestretcht, in de masterdark verschijnen opeens strepen die je in de masterbias niet ziet. Dus dark calibratie wordt hierdoor bijna een must, met heel aggresieve dithering (20-40 pixels) en veel opnames kan je het mogelijk bij bias laten, maar anders niet. Het calibratie filmpje van Sara Wager is een voorbeeld waarin bias calibratie voldoende is, daarom laat Sara de darks achterwege.APP-ED-MB-strongStretchAPP-ED-MD-strongStretch
    Theunissen replied to the topic Square star "centroids" in the forum Astro Pixel Processor
    Mabula, I just noticed it (before). To make comparison somewhat easier, this is the M31 image (crop) processed by you ... and of course, i'm pixel peeping ... if I enlarge the image I can see square "centroids". I'm more interested in the cause (and hence solution) then anything else ... MarcM31-Marc-preview-1
    I noticed the following before, I wasn't entirely sure about it, now I am. When I compare a stack, for example NGC7000 made with APP and the stack made with PI the stars (integration result) in the APP stack have a more square appearance. The attached image shows the APP stack left, and the PI stack right (only auto stretched). Of course, this is pixel peeping, but this effect is very noticeable in my wide field results. Is it possible that de Adaptive Airy Disc (Debayer Algo) is cause of the above? https://www.astropixelprocessor.com/community/rfcs-request-for-changes/square-star-centroids/ Square centroids
    Hi @keesscherer, Thank you, I have found the bug. It happened in -mosaic mode - not same camera and optics - dynamic distortion correction - projective model The bug caused to start the regression calculation with wrong initial parameters, in this case the "wrong" parameters couldn't be found. So a very good bug to solve 😉 Furthermore, I see another and even more serious bug in the star analyser when "filter star profile" is enabled with your data (first time I encounter this.. but must have affected other data processing as well): minimum star size 4 clip profile 0.1 filter on kappa 8 limit stars to : doesn't matter, screenshots with 1000 stars It's a serious bug, so very happy to have found it. 2 screenshots: first with "filter star profile" off, the other with "filter star profile" on. The screenshots show the "details" of "star map image viewer mode" on panel 41. Notice that with filter on, there are stars found with FWHM max, min of 1,00 & 1,00. These are bogus results, the star locations are rubbish as well... This must seriously affect registration in a bad way.StarAnalyserBugFilterOFFStarAnalyserBugFilterON
    Hi @keesscherer, Thank you, I have found the bug. It happened in -mosaic mode - not same camera and optics - dynamic distortion correction - projective model The bug caused to start the regression calculation with wrong initial parameters, in this case the "wrong" parameters couldn't be found. So a very good bug to solve 😉 Furthermore, I see another and even more serious bug in the star analyser when "filter star profile" is enabled with your data (first time I encounter this.. but must have affected other data processing as well): minimum star size 4 clip profile 0.1 filter on kappa 8 limit stars to : doesn't matter, screenshots with 1000 stars It's a serious bug, so very happy to have found it. 2 screenshots: first with "filter star profile" off, the other with "filter star profile" on. The screenshots show the "details" of "star map image viewer mode" on panel 41. Notice that with filter on, there are stars found with FWHM max, min of 1,00 & 1,00. These are bogus results, the star locations are rubbish as well... This must seriously affect registration in a bad way.StarAnalyserBugFilterOFFStarAnalyserBugFilterON
    There is a problem with dynamic distortion correction. When i only use panels 41+42 i get the Java error as shown in the screen print. When i swith the registration model from projective to calibrated projective the java error does not show. The resulting registration RMS is now 2.35, so still too high and there is some mismatch as you can see in the second screenprint.APP-panel41and42
  • Load More