Different Axis Size & Strange result when creating a Masterflat

Hi Henry,

Thank you very much for reporting this. It looks very odd...

Can you upload the data on which this happens here:

https://upload.astropixelprocessor.com/

username: upload

password: upload

Make a folder with your name and issue like Henry-MF-trouble and let me know once uploaded 😉 I will investigate and fix it a.s.a.p.

Regarding the dimensions, they are both right actually. The dimensions in the frame list are the actual image dimensions in the FITS file. The image in the image viewer has a raw border cropped off, because it is OSC data, this is normal. So the image viewer reports the dimensions of the cropped image with the raw borders.

Mabula

Hello Mabula, I have uploaded the dataset. The folder is called:Henry-MF-trouble. I hope it helps to find out what happened there.

With kind regards.

Hello Mabula, have you been able to test the data yet?

Hi Henry @minusman,

I am working on the whole calibration engine (optimization for speed and memory) at the moment and I will surely look at your issue in the coming days 😉 so I will make sure it is fixed.

Mabula

Hi Henry @minusman, I am now investigating your issue after a completely updated calibration engine for 2.0.0-beta7, see the release notes:

https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-2-0-0-beta7-release-notes-preparing-next-release/

You have uploaded data in 3 folders where all flats and flatdarks are duplicates per folder. If I make a MasterFlat using the 30 single flats and 30 single flatdarks, all works properly in beta6 and also in the current code with the updated calibration engine. Can you try again in beta6 and let me know the exact workflow that you perform to create the masterflat with this issue, so I can duplicate the issue? For now I can not duplicate it whatever I try. Even when I load the 3x30 flats (so per flat 2 duplicates, all works properly. I do not get the weird histogram and blue pixels in the raw border of the MasterFlat.

I created the masterflat using default and automatic APP settings.

Mabula

Hi Henry @minusman,

I also tried to calibrate the flats with your 600 sec darks to check if that was the issue, but even then, the MasterFlat is not showing your problem.

Mabula

Hello Mabula, thank you for taking the time to do this. That's why I have duplicate flats and darks in every session folder. In order to be able to understand exactly which calibration images belong to which session if I want to process the data again later. I've had problems with that in the past. My approach is true for each session that creates calibration images. I then looked at the master images and saw the colorful pixels on the edge. What made me suspicious, I thought it was a problem with the preview at first and switched back and forth between CPU and OpenGL but the pixels stayed. Then the interpolation deactivated in 0. But the artefacts can also be seen there. Then I looked at the master flats with other software, and there were also true artefacts visible at the edge. Then everything was reprocessed with Beta6 (Linux and Windows version), but the pixels remained. Then I re-transferred the images from the imaging PC again, re-processed again problem remained. New Flats Darks and Darkflats recorded and distributed again, pixels remained at the edge. Then everything was processed with pixinsight, there were no artefacts. So the data seemed fine so far. Then downgraded to Beta4 (Windows and Linux version), processed everything again and there were no more artefacts in the master flat. Then it occurred to me that something broke in the Beta6. Then I reported it in the forum. I might try again on my laptop with Beta6 if it's a machine problem. 

Best regards, Henry

Hello Mabula, you have checked it with Beta7. Maybe the problem no longer exists. I would have to test it there also times with version Beta7 if that is possible?

Hi @minusman, I also tested with beta6 and all is fine, I don't get your issue whatever I do. The thing is that between beta4 & beta6 nothing changed in the code relating to how a masterflat is created, so if it would happen with beta6 it should happen with beta4 as well I would think.

Anyway, please try again with beta6 to create new masters and let me know if you again get the issue or not 😉

Mabula

Hello Mabula, I have tried it with another computer. The same result with Beta6, I have also tested other data. I uploaded the result to the Henry-MF-trouble folder (subfolder Test 2 Bin1x1)including the frames.

Tried something else, I installed APP Beta6 only for me as current user (option 2 in installer "C:\Users\[User]\AppData\Local\Programs\astropixelprocessor" ). And again created different masterflats. See there suddenly everything in order. This of course crazy 🧐 .

With kind regards.

Hi Henry @minusman,

Do you have both 1.083 and 2.0.0-beta6 installed at the same time?

Please do not do this on Windows, it messes up the windows registry it seems and creates weird problems definitely.

I will test now with beta 6 installed for all users, to see what happens here 😉

Mabula

Posted by: @mabula-admin

Hi Henry @minusman,

Do you have both 1.083 and 2.0.0-beta6 installed at the same time?

Please do not do this on Windows, it messes up the windows registry it seems and creates weird problems definitely.

I will test now with beta 6 installed for all users, to see what happens here 😉

Mabula

@minusman On my computer with beta6 installed for all users, all works fine as well... Seems a windows registry issue then somehow, very weird indeed.

@minusman,

While investigating your data, I see that some of your darkflats have a serious FITS header issue as well. I think you should possibly inform APT that they create bad FITS headers here or somthing is off when the data is saved:

For instance, if I load the (flat) dark :

Cali-Bilder_DF_UVIR-Cut_2022-11-03_23-02-17_11119_3.07813s__-5C_Bin2x2_G120_FP16902_ZWO_ASI294MC_Pro__Color.fit

Our NASA FITS loader indicates:

nov. 18, 2022 5:43:34 P.M. nom.tam.fits.HeaderCardParser parseComment
WARNING: []: Non-printable character(s), e.g. 0x0, in [????????????????????????????????????????????????????????????????????????].
nov. 18, 2022 5:43:34 P.M. nom.tam.fits.Header forceEOF
WARNING: Junk detected at 5855040.
nom.tam.fits.FitsException: Not a proper FITS header: at 5855040

Luckily our FITS reader will ignore this header error, but it indicates an error in how the FITS file is created here.

Thanks Mabula, I'll keep watching. And I will forward it to Ivo from APT. Maybe we can get closer. Thank you for the time and best regards Henry.

Hello Mabula, a question about the Nasa Fits loader. Which one is that exactly, or where can you download it? I would like to do some research on my data myself. Best regards, Henry