Astro Pixel Process...
Clear all

[Closed] Astro Pixel Processor 1.081

1 Posts
1 Users
Universe Admin
Joined: 7 years ago
Posts: 4098
Topic starter  

Astro Pixel Processor 1.081, 2 fixes for the Correct Vignetting tool

  • FIXED, CORRECT VIGNETTING TOOL, artificial masterflat creation from the modelled vignetting profile had a bug on RAW data from consumer camera's (Canon, Nikon, Sony etc). The bug caused the artificial masterflat to overcorrect. This is now fixed.
  • FIXED, CORRECT VIGNETTING TOOL, APP 1.080 had a small bug, if you would start the Correct Vignetting tool, it would warn about the data not being background calibrated to be able to do Star Color Calibration. This is fixed.


Astro Pixel Processor 1.080, which was released 1 week before 1.081 which was a very big update including Fujifilm RAF support:

  • IMPROVED/FIXED, OPENGL INITIALIZATION LINUX, there was a critical bug in the OpenGL library with Linux Mesa drivers for older AMD/ATI graphical chipsets. This bug was reported upstream and has finally been solved since the latest library version no longer has the critical bug on the systems were the problem was reported: . The issue caused APP not to start. APP should start now on all Linux distributions with OpenGL enabled if the graphical drivers support OpenGL.

  • EXTENDED CAMERA SUPPORT WITH FULL SUPPORT FOR FUJIFILM RAF FILES including SUPERCCD & XTRANS camera's: please find the tested Fujifilm camera models here:  
  • ADDED, Fujifilm X-Trans demosaic algorithms: all the Astro Pixel Processor Bayer CFA demosaic algorithms like Adaptive Airy Disc, Bilinear, SuperPixel, H-alpha, Ha-OIII (for dual/triple narrowband filters) now have an X-Trans demosaic implementation as well. So the demosaic algorithms that you can choose in 0) RAW/FITS will apply to X-Trans camera's as well. Please see the following screenshots that illustrate it:
FujiFilm XTrans support
FujiFilm XTrans support bilinear
FujiFilm XTrans support adaptive airy disc
FujiFilm XTrans support superPixel
FujiFilm XTrans support Hydrogen alpha
FujiFilm XTrans support Oxygen III
FujiFilm XTrans support Ha OIII mono
Demosaic Algorithms for Bayer And XTrans sensors
  • ADDED, 0)RAW/FITS, COLOR FILTER ARRAY (CFA) PATTERNS, you can now also select X-Trans CFA patterns if needed. Please realise, that for RAW file types like the Fujifilm RAF files, the correct pattern is automatically detected and used if you leave the setting at supported
Color Filter Array Patterns including XTrans patterns
  • IMPROVED, FORCE BAYER/X-TRANS CFA, the tooltip has been adjusted to make more clear why you need to enable this if your data is shown without color, when it is in fact color data.
Force Bayer XTrans CFA
  • ADDED, X-TRANS DRIZZLE, just like Bayer Drizzle, you can now use X-Trans Drizzle to only drizzle the Color Filter Array (CFA) data of your sensor without demosaicing the data.

  • IMPROVED, BAYER CFA DEMOSAIC ALGORITHMS, several demosaic algorithms have been improved/upgraded to reduce color issues in stars (like purple star cores) and to improve the Signal to Noise Ratio by reducing noise. The resulting color reproduction of the new algorithms is improved by preventing under- and overshoot for the interpolated values. It means noise is further reduced as well in both the blue and red channels. Sharpness of the algorithms is still maintained and Star Color Calibration should give initially better and more stable results with the default settings. The improved algorithms are
    • Adaptive Airy Disc
    • Adaptive Edge
    • Oxygen III (in this case the blue bayer pixels are better used for reconstruction the OIII signal in combination with the green bayer pixels)
    • Ha-OIII multi-narrowband filter algorithms. (in this case the blue bayer pixels are better used for reconstruction the OIII signal in combination with the green bayer pixels)

From discussion of APP 1.080-beta2 versus 1.079: APP 1.079 versus APP 1.080-beta2 - FWHM, noise, SNR & (Star) Color accuracy comparison ! 

Color Accuracy 1.079 versus 1.080 beta2


  • IMPROVED, BAD PIXEL MAP, to create a good bad pixel map for a camera's sensor, especially with enough hot pixels detected and... not too much, the user would have to tweak the hot pixels kappa value to get a good amount of hot pixels detected from the loaded darks and/or masterdarks. A good value for any sensor is about 3%. We can argue this from extensive experience for both CCD and CMOS camera's. With a detection of 3%, almost all hot pixels will be detected on almost all sensors and it will also prevent overcorrection by correcting pixels that don't need correction with the Bad Pixel Map. APP can now do this automatically for you. If you set the create BPM to automatic (which is the default now), APP will only create a new Bad Pixel Map, if you haven't loaded one already for the loaded light frames and calibration frames. And it will automatically find a suitable hot pixels kappa value as well for you. The cold pixels % will be fixed to 10% in the automatic mode, because that works well on almost all data even with strong vignetting in the flats.
Fully automatic BadPixelMap creation
Fully automatic BadPixelMap creation console output
Fully automatic BadPixelMap creation BPM details
  • IMPROVED/FIXED, UPDATING FRAME LIST PANEL AND SORTING OF FRAMES, updating of the frame list panel at the bottom of the user interfaces has been greatly improved. It is much faster now. If you load more than 500 frames, then after the star analysis step, the updating and sorting on the analytical result for all frames would start to take several seconds in the old APP version. With more than 1000 frames, it really becomes very slow ! This problem is now completely solved. The updating and sorting on analytical results is now almost instant, even with more than 1000 frames loaded and analysed.
  • IMPROVED/FIXED, NUMBER OF FRAMES TO STACK SLIDER, this issue was related as well with the updating speed of the frame list panel. If you have 100s of frames loaded, even more than 1000, adjusting the number of frames to stack in 6) Integrate will no longer freeze the application. Instead the new frame selection based on the number of frames to stack slider is performed almost instantly.
  • FIXED, NULLPOINTER WHEN MATCHING FILTERS/SESSION AND FRAMES, sometimes a nullpointer could be thrown when APP needed to find internally which filter and/or session was chosen for a certain filter. This null pointer exception will no longer occur.
  • FIXED, LNC INFO EXTENSION ON INTEGRATION FILE, this LNC extension has been removed for simpler integration/stack names. ALL LNC information can now be found in the integration FITS metadata.
  • FIXED, HDD SPACE NEEDED IN MULTI-CHANNEL/SESSION MODES, if you would choose to integrate per channel and all channels into 1 integration for instance in 6) integrate, APP would not report the correct HDD SPACE needed to complete all integrations in the old version. APP will now correctly calculate the amount of space needed to be able to integrate all the channels into 1 channel, which is the space which is needed for the separate channels combined.
  • FIXED, RAW CONVERSION OF FRAMES THAT DON'T USE THE WHOLE SENSOR BUT A CROP OF THE SENSOR, as reported here for an Olympus ORF file APP was not able to process the ORF file correctly because not the whole sensor was used in the exposure. This is now fixed for all supported RAW file types.
  • FIXED, HISTOGRAM IN TOOLS, if the image viewer was set in the star map mode and you would start a tool like the RGB Combine tool, the histogram would not work. This is now fixed for all tools.
  • IMPROVED, INTEGRATION CONSOLE OUTPUT, while performing the actual integration, the console will now show : integrating pixels 3245256 to 3249528 of 8851203 instead of only integrating pixels 3245256 to 3249528 . So the total number of pixels to be integrated is shown as well.
  • FIXED, AUTOMATIC FILTER ASSIGNMENT FOR COLOR FILTER ARRAY DATA OF RGB, if you would load a CFA Master in FITS format, APP would automatically assing a MONO filter, where it should be a RGB filter by default. This is now fixed. This will make sure that these masters will automatically match with their light frames which also should be RGB filter data in that case.
  • FIXED/IMPROVED, STAR ANALYSIS, some further improvements have been implemented in the star analysis module based on test data with large stars (FWHM > 10 pixels) and only 10-50 stars available. The improvements help to detect more stars and fainter stars in these cases so more frames will pass star analysis. APP will now detect enough stars in frames were it previously failed to detect at least 6 stars. The following example shows such a light frame where APP previously failed and where it now passes:
Star Analysis detect more faint stars starmap
Star Analysis detect more faint stars frame
  • IMPROVED, DATA CALIBRATION, APP will now issue a clear warning if the calibration data only contains 8bits data. Performing data calibration on 8bits data with 8bits masters will never work properly or give satisfactory results, so APP will simply warn the user that the data is insufficient and it will abort data calibration on the light frame.
    Warning on 8bits data
  • IMPROVED, CALIBRATE BACKGROUND TOOL, if you load data that is already Background Calibrated into the Calibrate Background tool, APP will warn you if you want to do it again on this data. Background Calibration is also automatically done by the Remove Light Pollution tool, so if you have run that tool earlier, and then run the Calibrate Background tool, you will get the warning, that there is no need to run this tool, since it was already done by the Remove Light Pollution tool.
Warning on already Background Calibrated data
  • IMPROVED, STAR COLOR CALIBRATION TOOL, previously, if you started the Star Color Calibration tool on data that was not Background Calibrated, the tool would not start and issue a warning that you would first need to perfrom Background Calibration. This behaviour has been changed. Now the tool will inform the user that either the remove light pollution tool or the calibrate background tool should be started first and it will offer the user the choice of which tool to start first. When done, Star Color Calibration will automatically continue on the result of either the remove light pollution tool or the calibrate background tool. This should give a better user experience 😉
Star Color Calibration start with uncalibrated background data
This topic was modified 3 years ago 3 times by Mabula-Admin