If the first Image in a stack of FITs is Grayscale but the rest are RGB, the resulting stack is Grayscale, not RGB

[Didge]

Hi,
I just tried several times to build a stack from 48 x 48-bit RGB astro-images, but the resulting image was always grayscale.

It turned out that 2 images in the middle of the stack were actually 16-bit grayscale (damaged somehow during recording ?) and had a '-' character added to the filename instead of an underscore '_', so they appeared at the top of an alphabetically sorted list.

When I imported the 48 images to create the stack, the 2 grayscale images went to the top of the stack in line with the sorting order.
I didn't even notice this at first because the window width was too narrow to display the long filenames.

Even though there were 46 x RGB images in the stack below these 2 grayscale images, the entire stack was always compiled as a grayscale image. Checking further, the resulting image was actually RGB, including the default RGB colour profile, but the image had no colour content.

Turning one grayscale image off before building the stack made no difference - the result was still grayscale.
Turning BOTH grayscale images off gave me a nice RGB result !
Also, renaming the offending files so they appeared at the BOTTOM of the stack (rather than the top) also gave me an RGB result, even when they were BOTH included in the stack build.

Definitely a tricky one to fault-find - but something is not right with the way AP manages the colour profiles of images when building a stack.

Gary

 

 

[Gabe]

Hi @Gary.JONES,

Sorry for the delayed reply. 

This is expected. You can convert an RGB to grayscale, but you can't convert a grayscale image to RGB. I think the algorithm is doing the right thing here. It could either merge everything to grayscale, or throw an error. You can't really have a mix of RGB/Grayscale in one stack. 

[Didge]

Hi Gabe,
Many thanks for the feedback ...

I hope you don't mind if I disagree

There are several issues here :-

1. Yes you can convert a grayscale image to RGB, its just that R=G=B in this case. Otherwise they are the same (assuming they have the same colour profile).

2. The issue I described in my original post only arose when the grayscale image was the first one in the stack.
I'm assuming AP uses this as the reference image to which all the other images are aligned.

If the first image is colour, and the grayscale image is anywhere else in the stack, then AP builds a colour stack.

3. So, AP DOES go ahead and build a colour stack that includes a grayscale image, provided the first image is colour, even though a grayscale image is in the stack somewhere, which is different to what you describe as expected behaviour.

IMHO this is inconsistent - AP should not behave differently because the grayscale image is first in the stack vs being second in the stack.

Whether the first image is Greyscale or not, AP can still use it as a reference for alignment, but still integrate the grey image with a bunch of colour ones. IMHO this should be the expected behaviour, 

In my case, AP threw out colour information from 46 perfectly good images because the first 2 images appeared to lack colour, even though they were actually RGGB.

4. The grayscale images in my stack were captured in the same way as all the other colour images, but displayed no colour information.
I have no idea how that happened.

But it's easy to imagine cases where you WANT grayscale images in the stack to contribute to luminance.

5. AP should really scan each image as it's imported, and flag a warning if any image has a colour profile different to the others,
then let the user decide what to do.

6. There's also another issue here ...
Let's say you import images into a stack, and then select one so you can look at it more closely in the viewer.
You expect the selected image to be displayed in colour if it's RGGB, but the image is shown in grayscale, provided the first (grayscale) image is still flagged as visible.

If you switch the grey image to INvisible, then the selected RGGB image is displayed in colour. This definitely not the behaviour you would expect.

7. And the answer is ...
The cause of this problem turned out to be that the 'grayscale' image had a corrupted bayer pattern identifier.

The RAW options in AP were set to 'Inferred' - so it 'inferred' a monochrome profile rather than RGGB.
When I changed the RAW option to RGGB, the previously 'grayscale' images burst into full colour images, as did the entire stack.

8. So, adding to what I said in 5 above, when FITS are imported, any image that has a different BAYER identifier to the others should be flagged, and let the user decide what to do

Overall, AP seems to be taking info from the first image and inferring that to ALL the other images, which IMHO is not expected.

Regards,

Gary

 

[Gabe]

8 hours ago, Gary.JONES said:

2. The issue I described in my original post only arose when the grayscale image was the first one in the stack.
I'm assuming AP uses this as the reference image to which all the other images are aligned.

If the first image is colour, and the grayscale image is anywhere else in the stack, then AP builds a colour stack.

My bad. I misunderstood your original post. Yeah, I agree in this case. It should be consistent. Can you upload a few rgb/grayscale fits from that set so I can log this with our developers? https://www.dropbox.com/request/YcQy11XUrp7nRjTwmqg0

[Didge]

Done

The images ending in 0021 and 0035 are full-colour FITS, but the Bayer metadata is missing, so AP 'infers' them as grayscale.
If you select RGGB, then they display OK.

The other 3 images were captured during the same imaging session, but have intact metadata.

Let me know if you need more info :)_

Gary

[Gabe]

You only seem to have attached 3 files (ending in 0021, 0035, 0001). But was expecting 5 based on your last reply. 

[Didge]

Oh - I did actually attach 5 images ... have just re-sent the ones ending in 0002 and 0003.

Gary

[Gabe]

Thanks. I spoke to our developers and this behaviour is intended. We have a dedicated "RAW options" window where you can manually set the FITS Bayer pattern. (Default Inferred)

[Didge]

Hi Gabe,

Thanks for the feedback.

IMHO (as a professional computer scientist specialising in UX), this behaviour is wrong - for 4 reasons :-

1. If the stack contains images of more than 1 type, then AP should display a warning to let the user know.
I dont know how often a user would want to build a single stack using images from cameras with different bayer patterns,
but I suppose it is possible. 

2. If there is no metadata in the image to define the Bayer pattern, then what does AP 'infer' from ?
If no Bayer pattern is defined, then AP should flag an error.
It does not make sense to infer Greyscale as opposed to something else - esp when the image contains colour data.

3. My images were all RGGB, its just that the first 2 had bad metadata - AP should have a way to know that.

4. AFAICT, there appears to be no way to make AP default to anything but 'inferred'.
In other words, every time you create a new stack, 'inferred' is set by default, you have to go in each time and change it manually.
What I'd like to do is make AP always open FITS as 'RGGB' - without inferring anything.

I hope that all makes sense

Gary

[Gabe]

4 hours ago, Gary.JONES said:

What I'd like to do is make AP always open FITS as 'RGGB' - without inferring anything.

I suggest you create a new post in the feedback section with your suggestions.  https://forum.affinity.serif.com/index.php?/forum/55-feedback-for-affinity-photo-on-desktop/