[Closed] Astro Pixel Processor 1.072

Astro Pixel Processor 1.072

• NEW, full support for SONY ARW raw files, Sony raw files will now be fully supported in APP thanks to use of the LibRaw library which is an extension of Dave Coffin's dcraw code. I have tested about 70 camera models and I think all models of the latest 5 years are included and thus supported. The full list can be found here: https://www.astropixelprocessor.com/community/faq/sony-arw-tested-camera-models/

Support for RAW file formats of the other brands like Pentax, Fuji, Olympus, Panasonic, Adobe DNG will be supported in the versions following APP 1.072...

• ADDED, Nikon Camera Support, D3500 is fully supported now, the mirrorless camera's Nikon Z6, Z7 are supported, but only the compressed NEF files. These compressed files are lossless so it's the recommended format as well to shoot your data. The uncompressed NEF's of the Z6 & Z7 are not supported yet, because Nikon has changed something here. The uncompressed NEFs are still compressed and need a new decoder to be able to read them it seems. Latest versions of dcraw/libraw also can't read these yet...
• IMPROVED, BAYER DRIZZLE on BAYER CFA data, if the APP user selects drizzle integration when Bayer CFA data is loaded (also with Force BAYER CFA in 0) RAW/FITS) the user is warned that he/she can better use Bayer Drizzle integration instead. Selecting Drizzle integration on Bayer CFA data would mean that the data is still debayered and then drizzled, which is not a recommended workflow. If you want to use Drizzle, it's preferred to select Bayer Drizzle if you have Bayer CFA data.
  

  

• IMPROVED, DRIZZLE/BAYER DRIZZLE, if you apply Drizzle/Bayer Drizzle integration with too small droplets combined with a too small amount of light frames combined with a too large scale increase (so 3 factors play a role here), then you run the risk of creating an incomplete Drizzle Integration. An incomplete drizzle integration has zero pixel values on places where no drizzle drop landed from drizzling... this can happen easily especially with small droplets, or a small amount of frames. APP will now correct such an incomplete Drizzle/Bayer Drizzle integration by performing an interpolation of surrounding pixels of a zero-pixel so it can be replaced with a best guess from interpolation. The following images illustrate the problem and the improvement described here. I performed a Bayer Drizzle integration of only 6 frames of a Nikon D5100 (OSC, RGB) with a scale increase of 1.5x and droplets of 0,75 pixel. First check how a single frame looks when we view it in the l-c-r-normalized image viewer mode, shown is the full field of view of the integration and a crop of the Cocoon Nebula:

If you have set the integration mode to Drizzle/Bayer Drizzle and you view the light frames with the registration applied in the image viewer, you will actually see how the drizzle droplets are placed on the target pixel grid of the resulting integration, so it is normal that this might look a bit odd to you. Not all pixels in the integration pixel-grid will receive a drizzle droplet. That is essentially how drizzle works to increase sharpness/resolution in the integration 😉

Now let's look at what happens if we simple integrate the 6 frames with Bayer Drizzle, without performing a compensation for the resulting incomplete drizzle integration (caused here by using too little frames combined with too small droplets and a too large scale increase.):

This is how the compensation will look like now in APP 1.072:

You can see that the result is now much better, allthough we can also see that still not all pixels are non-zero where we would expect non-zero values, especially at the border. The only way to solve that is by

• • adding more frames or
  • increasing the droplet size or
  • decreasing the scale factor or
  • any combination of 1-3
• FIXED, EXIF metadata, some TIFF files have a makernote field in the Exif IFD without a camera brand as make tag according to TIFF specification. APP could not load these. This exception is now caught so these TIFF frames will load now.
• FIXED, TIFF Image Loader, some TIFF frames were not compatible with the Tiff loader in APP, to improve TIFF compatibility, I have added another TIFF loader that is capable of loading more types of TIFF images.
• ADDED, TIDD IFD/EXIF metadata, added recognition of more Tiff tags in the metadata including GPS tags.
• FIXED/IMPROVED, TIFF image loader, previously, to get a TIFF file's metadata, the whole image was loaded. When adding a lot of Tiff frames with one of the load buttons, this was very slow for Tiff frames because all images needed to be loaded to get the metadata. This is no longer the case, so the initial loading of Tiff frames into APP is now much faster.
• FIXED/IMPROVED, JPEG image loader, previously, to get a JPEG file's metadata, the whole image was loaded. When adding a lot of JPEG frames with one of the load buttons, this was very slow for JPEG frames because all images needed to be loaded to get the metadata. This is no longer the case, so the initial loading of JPEG frames into APP is now much faster.
• IMPROVED, Console Panel & ProgressMonitors, the output in these windows has been improved to better show fast output of processing tasks. The scrolling of the text is only enabled now when the vertical scrollbar is set at it's lowest position. So if you move the scrollbar to the top while performing a processing task, the scrolling text of the output stops. If you move it to the bottom, scrolling starts again.
• IMPROVED/FIXED, Loading of a Bad Pixel Map with missing metadata, it was not possible to load a Bad Pixel Map if the frametype metadata "Bad Pixel Map" was missing. You can now still force a frame to be used as a Bad Pixel Map allthough the metadata is missing.
• IMPROVED, Loading of a previous integration as a light frame, loading of a previous integration as a light frame was only possible if you manually disabled/deselected the auto detect Masters & Integrations checkbox in 0) Load. If this setting is still enabled, you will be asked if you still want to load these previous integrations as lights for a new integration so you can still proceed without having to disable the checkbox first.
• FIXED, PreviewFilter, if the DDP preset was set to no stretch (data as is) you could not adjust the Black(B), White(W) and Gamma(G) sliders. This is now possible. So by setting the preset to no stretch (data as is) you will only disable the DDP function in the previewfilter and still be able to adjust the black, white and gamma levels.
• FIXED, Integration MemoryToFileMapper, in some cases, a Buffer Underflow exception could occur while integrating frames. This seemed to happen only very infrequently, mostly with very large datasets (100s of frames)  and usually an external harddrive was involved. It was reported to happen on both MacOS and Windows, not on Linux as far as I know. I have made several adjustments now to prevent the exception from happening and if it still does happen (due to an Operating System level IO error), it will be caught cleanly now so the integration can still continue. The issue was reported recently here : https://www.astropixelprocessor.com/community/main-forum/what-is-the-best-way-to-combine-multiple-sessions-over-time-other-then-redoing-all-every-time/#post-4991 Theoretically, there is also the possibility of a BufferOverflow Exception, but that never happened as far as I know, anyway, if it does happen, it will also be  caught cleanly now so the integration can still continue. Both exceptions should never occur again while integrating.
• FIXED, Dynamic Distortion Correction, Same Camera and Optics, a bug has been solved that could manifest itself when dynamic distortion correction was enabled together with Same Camera and Optics. In some cases, dynamic distortion correction is not needed at all to get good registration and if it was enabled though, it could happen that the distortion correction would apply an abnormal distortion of the field of view as experienced by several users. This abnormal distortion should no longer happen. The error would occur if the frames to register would only have very small translations and/or rotations between them. An example is shown here, 10 frames were registered with dynamic distortion correction and same camera and optics enabled in APP 1.071. The 10 frames only have very minor translations and rotations between them:

In APP 1.072 this bug is now detected, Multiple View Dynamic Distortion Correction will only be applied if the translations and/or rotations are not too small. Only then, a meaningfull optical distortion correction model can be calculated:

• FIXED, IMPROVED, STAR ANALYSIS, star detection has been further improved by adding an algorithm that better discrimates between hot pixels/small FWHM stars/big FWHM stars. Some users experienced difficulties because hot pixels were detected as stars. The added algorithm studies the star size/FWHM distribution initially found. The details of the distribution are very usefull to make the discrimination between hot pixels/small FWHM stars/big FWHM stars.
• IMPROVED, GUI frame list panel scrolling with up/down keys, you can scroll through the frame list with your up and down keys. Previously, the vertical scrollbar was not adjusting to the movement that you made in the list, so you could have been selecting an image outside of the visual range of the frame list panel... The scrollbar will now adjust so you will automatically scroll through the list and you will keep a visual check on where you are in the list.