[Solved] Encountered error in module CombineNewBufferedImage with 16 panel Mosaic

I'll let Mabula know, we might need some data if this is not known already, thanks for the clear description!

@vincent-mod I think it is a limitation on the pixel size of the image that can be handled by the RGB tool, I tried using the "Cropped" versions of the mosaic panels, and as expected, the exception number changed from -1663639684 to -1836477244

I have also tried redicing the files from 32Bit Fits to 16Bit Fits to check if it was a file size issue, and the same result with the cropped image, same number of -1836477244, so I definitely think it is something to do with the image dimensions

Current image size is 35314x23206

I have alto noticed that APP changes the FITS Header from "FILTER" to FILT-1 which causes the mosaic not to recognise the filter header during the adding of the channels, requires a manual assignment

Original Ha Frame:

Mosaic Ha Panel:

Full Mosaic:

Is there a reason for APP to change the Filter Tag in the FITS Header?

Taking the base image of 35314x23206 and applying a resample in Pixinsight, I get the following number for the error at the specific image sizes:
100% 35314x23206 (819,496,684 pixels) : Error -1836477244
95% 33538x22039 (739,143,982 pixels): Error -2077535350
94% 33194x21813 (724,060,722 pixels): Error -2122785130

93% 32854x21589 (709,285,00 pixels): Successful Re-calculate

Hope the above data helps

Hi Simon @stastro,

Thank you very much for sharing this issue. Indeed, it must be caused by reaching the image dimension limit in APP.

To be sure, can you upload the data so I can fully test and make sure this error is dealt with appropriately?

https://upload.astropixelprocessor.com/

username: uploadData

password: uploadTestData

Please make a folder with your name and issue like: stastro-RGBCOmbine-RGBLimit

and let me know once uploaded 😉

Thanks!

Mabula

Since it is image dimension related, I will scale them down to 8-Bit to make them smaller file size wise, otherwise it might take a while to upload

Data is uploaded

STAstro-RGBTool-RGBLimit

8Bit files, tested and same result, so it is definitely dimension limit being hit

Hi Simon @stastro,

I have fixed this issue in the 2.0.0-beta25 release with instructions to inform you how to create the composite within the image size limit of APP:

https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-2-0-0-beta25-release-notes-work-in-progress/

Thank you very much for reporting this 😉

Mabula

Hi Simon @stastro,

Please try 2.0.0-beta25 which has been released with the fix for this issue.

https://www.astropixelprocessor.com/downloads/

Mabula

@mabula-admin Yep that works

Will APP ever support larger than 2.1gpx in the RGB tool?  What is the limitation?

Also did you see my note about FITS metadata changing "FILTER" to "FILT-1"

Wasn't sure if FILT-1 was a FITS Standard that other apps recognise, I know off the camera the variable is named "FILTER"

Hi Simon @stastro,

Great 😉 at least the error is now properly caught, and the warning shows you the scale factor needed to be able to complete the composite as large as possible within that image size limit.

The limit is a limit in our development platfrom, the size of an internal array can't be larger than 2^31 = 2.1G which is the main factor here.

I am sure that we can adjust this to offer a theoreritcal unlimited image size, but I need to develop/implement a modified version of the image instance that we currently use 🙂

As soon as 2.0 stable is released, this is probably our biggest next TODO on our list because of APP's mosaic capabilities and also because the sensors are getting bigger and bigger in pixel dimensions... Together with removing that image size limit. we will work an a more efficient preview filter and will also do big work on the mosaic registration algorithms. So that is what we have outlined going forward 😉

Yes, FILT-1 is an APP internal tag, it is not in the FITS standard, FILTER is the fits standard. But I had to introduce this since you can make intergrations combined of several filters. I have opened an issue to check what APP currently does with these tags and if FILTER should always be there alongside FILT-1. What would FILTER be if we indeed combined multiple filters for instance?

@mabula-admin I suppose you have to look at it from this aspect.

With OSC Cameras, users typically would never use the Filter Tag, because most do not use EFW's with an OSC, me on the other hand I used to use an OSC just to flip between the Dual Band Filter and the L-Pro filter, so I would have that in my filter tag.

Once an image is combined, the FILTER tag becomes irrelevant, because the image is now a colour image as opposed to a single filter, maybe if the image is combined in APP, it should be something like

Filter:
RGB
LRGB
SHO
HOO
HaRGB

Etc, depending on the colour palette used in the RGB tool

If I combine my filters in PixInsight, the resulting RGB image has nothing specified in the FILTER tag, it simply does not exist:

Hi Simon @stastro,

I have fixed everything for the 2.0.0-beta33 release,the FILTER tag, FRAMETYP tag and moving all distinct FITS tags from the reference or source FITS files to the output FITS images that APP produces across the whole application. So all relevant tags for plate-solving like RA and DEC coordinates will remain present now.

This is from the release notes:

• IMPROVED and FIXED, keep FITS HEADER TAGS from reference/source files including RA, DEC, FOCALLEN, XPIXSZ, YPIXSZ, DATE-OBS etc...
  

  As mentioned in several topics like this one  https://www.astropixelprocessor.com/community/rfcs-request-for-changes/include-more-fits-header-information-in-the-integration/#post-31871 , whenever APP would make a new FITS file, old FITS tags from the reference or source file would be lost like the RA and DEC coordinates of the object in the image. This is now fixed for the entire application. Calibration masters will still have all the information from the capture software like gain and sensor offset if present, integration files will have all the distinct FITS tags from the reference frame which should make sure that all information is correct like the RA and DEC coordinates. And saving FITS files in all tools will keep the original FITS header tags that APP will not add itself. The FTIS header will have a note that indicates when the transferred tags start from the source/reference file: HDU1 - NOTE-XX = 'Distinct header tags from the original/reference frame follow below' 
  See the below screenshots for the FITS headers that APP will now produce keeping the distinct FITS tags from the reference or source FITS files. Also note the addition of FILTER tag and FRAMETYP tags as described in the release notes below:

I will try to release 2.0.0-beta33 in the coming days for sure 😊 !

Mabula