Minor problem V2beta1

Are these the same files though? I see lpc, cbg in one window and not in the other. But if it indeed is different for the same file, that would be interesting to know!

Hi Vincent,

When I save the file from the main window on the right hand side, as a fits file then it seems to have lost the stars.

When I save the image as a jpeg file it goes ok!

I didn't use the star reduction tool, only the light polution removal.

Will test a bit more, maybe I just messed up ( as usual ).

My workflow is rather standard:

lights, mflat and masterdark are passed through all sthe steps resulting in a final integration image showing in the image viewer.

I then selected the lightpolution removal tool ( selecting the image in the viewer ) and doing the procedure to remove the lightpolution, resulting in a good looking image.

I saved this image as a fits and loaded into PixInsight, all ok!

Then I went to the right hand side, selected neutralize background, saturation and save as fit file, that loaded into PixInsight gave me that strange looking image.

When saved as a Jpeg file all went fine! ( see atatched finished image, minor tweaks in PixInsight, so almost all done in APP )

This was shot from my heavily lightpoluted balcony ( SQM 17,4 )

under full moon.

Mmmm, strange, are you sure you're saving the image in fits fully stretched etc?

After some more testing I see it can be reproduced!

1) Load some image into APP and double click on it in the file list

2) On the right hand panel select neutralize background and saturation

3) Then when saving, in the popup menu select 32 bit integer fit as the output format.

Load the resulting file in PixInsight and voila, the problem is there.

I double checked with other images from other directories and they show the

same behaviour.

Maybe I should not select 32 bit fits as output? ( eventhough it is on the dropdown

list )

@vincent-mod Hi Vincent, yes it was stretched to my liking.

Which version of APP are you using? I'm wondering if PI is performing a stretch or something, it should be saved as a stretched fits file, is that correct?

@vincent-mod Hi Vincent, the latest V2.0 beta 1 of APP and the latest version of PI.

The image should have been saved as a stretched fits file.

You can try with whatever image you have locally and follow the steps above outlined to reproduce the "error".

I am wondering if I can't save as a 32bit fits file. ( in 1.0.83-4 I didn't have this problem )

I did, for some reason I can't reproduce it though. Would you mind sharing the fits file you're using?

@vincent-mod Yes, no problem, I will upload a couple of them! ( to a folder like Mert-V2betaproblem is that ok? )

Perfect!

I uploaded 3 files from diferent dates and different objects, following the 1,2,3 procedure

on my laptop they all fail with the same symptoms.

Camera used was a ZWO 1600 OSC but that doesn't matter I think.

Thanks, I'll have a quick go at them.

Curious how that goes!

So I see they are all already stretched, so I'd then load them in and select "no stretch" in the preview filter before saving. I also select 32-bits fits float, which seems to then work much better. I usually only use the saving of files on linear files that are then stretched in APP, not on already stretched files (unless you deselect a few options).

@vincent-mod The case is that after APP letting do it's thing to get an integrated image, use the stretched image as seen in the viewer. Then saving that view as a 32 bits integer Fits file produces the error. I only uploaded these files to show the effect quickly.

I can also upload unstretched files, but I never used 32bit floats if I'm not wrong.

In version 1.0.83-4 I never had this "problem", don't know, but it seems as if something goes wrong there.

Ah ok, yes if you then could upload the unstretched fits files like you have straight after integration, that would be nice. For me it's important to recreate the problem here to be able to see what might be going on. 🙂

@vincent-mod Hi Vincent, just uploaded the 3 files as saved by APP without any interaction of me.

Thanks, I'll have a look today.

Ok, so I saved using 32-bit float and got this:

Indeed, choosing integer doesn't look nice, but I think this is due to the difference between integer and float, where with float you have way more possible values to deal with. Have to say, I'm not sure in what circumstance integer is used... let me ask Mabula. 😉

Scratch my now deleted follow up on this. You indeed discovered a bug! Loading of 32-bit int works fine in APP, but saving indeed has an issue. Thanks a lot for getting this to our attention! We'll fix it asap.

Thanks a lot Vincent for confirming this, it is easy to get around but nice to know I was not inventing strange things.

I hope to see the next release, this is very promising!!

Yep, float will not have an issue and I would even recommend to use that anyway, even when it is fixed.