Massive overcorrected master flat

[StarFlea]

Eureka!

I've obviously found it!
The crux of the matter is in the FITS header, but apparently somewhere else entirely! By comparing the various FITS files I've experimented with, I'm now sure where the problem lies:

In the master flat, the keyword IMAGETYP is set to 'Flat'. It should probably be called 'Flat Frame'.

I've now edited my original master flat file with a hex editor based on the list (https://cdn.diffractionlimited.com/help ... itions.htm). After that, it works wonderfully and the correction works as a master flat.

I suspect that SharpCap ignores the entire HEADER because of this faulty flag and then reads the FITS file as BOTTOM-UP by default, regardless of what is entered.

StarFlea

[admin]

Hi,

I'm afraid I'm even more confused now... Unless the issue is that other software does not like the 'Flat' header and prefers 'Flat Frame'...

SharpCap writes the FRAMETYP and IMAGETYP headers when writing FITS files, but does not pay any attention to them when reading FITS files - they are just thrown away when the FITS file is loaded into SharpCap.

I suppose it could be that whatever tool you are using to alter the FITS header is making other changes (inadvertently ) to the file and that is resolving the issue.

puzzled!

Robin

[StarFlea]

Hello again!

The hex editor is used to manipulate any file at the byte level. As you can see from the screenshots, only a few bytes were changed at the marked point. Otherwise, the file has remained the same:

Header original Masterflat-FITS:

Ori.JPG (168.76 KiB) Viewed 818 times

Header manipulated Masterflat-FITS:

New.JPG (138.02 KiB) Viewed 818 times

What do your functions/methods look like that you use to write and read FITS? Did you program them yourself or do you use ready-made or native libraries?
Perhaps this function/method cannot handle the flag?

StarFlea

[StarFlea]

So, now I'm confused too!

After thinking about it again, I did the following:
Created a copy of the original master flat and gave it a relatively simple file name: And now hold on tight: It works!

Could it have something to do with the file name?

My master flat is called: "MasterFlat_18_25_20_offset=1.139%.fits"

[StarFlea]

After some experimentation, I was able to narrow down the problem even further:

The following part of the FITS file name is crucial here: "offset=#.###%.fits"
where '#' stands for a number.

Is this read out somehow?

[StarFlea]

So, now I've experimented with the numbers in the file name. If I set this offset to 0.000, the frame is corrected perfectly, the higher the value, the more noticeable the incorrect correction becomes.

However, I don't quite understand the purpose of this component...

I don't know how that fits (or doesn't fit) with the mirrored image. Maybe the problem was never with the ROWORDER...
Sorry if I've raised a false alarm here!

I'm pretty confused myself now!

[turfpit]

Starflea

The following would be useful to help progress this:

• An unprocessed light FITS frame

• An unprocessed flat frame used to produce the problem master

• Capture settings files from the above

I have processed MaxIm DL (Diffraction Ltd) data with 'Flat Frame' in PixInsight and Astro Pixel Processor - no problems.
I have processed SharpCap and other capture programs data with 'Flat' in PixInsight and Astro Pixel Processor - no problems.

Maybe the problem was never with the ROWORDER...

If ROWORDER was the problem then astro imaging world wide would have probably collapsed.

Dave

[StarFlea]

Hi Dave!

Yes, you're certainly right!
Although I don't really know what to do with the "offset" in the file name either!

Even though I was pretty wrong with my initial assessment, at least the problem is now well-defined!

I'd like to upload some files, but the upload limit here in the forum is 1 MB.

[turfpit]

Starflea

A a link to a cloud based share is the normal technique for big uploads.

Dave

[StarFlea]

All right, here are the links...

https://drive.google.com/file/d/18SQVDa ... sp=sharing
https://drive.google.com/file/d/1BXDpfO ... sp=sharing
https://drive.google.com/file/d/1NocBvI ... sp=sharing
https://drive.google.com/file/d/1Q0o_7d ... sp=sharing

It will certainly be interesting if someone else tries to work on the files, perhaps with other programs.

I am considering to what extent I can influence the problem myself, but the "offset" entry is made by SharpCap during master flat generation...

StarFlea