How are Curves and Levels set when building an Astronomy Stack ?

[Didge]

Hi,
When creating an Astronomy Stack, AP automatically inserts a Curves adjustment layer and a Levels adjustment layer above the pixel layer.

AFAICT, the default values assigned to these curves and levels is the same, regardless of the colour content of the pixel layer.
In other words, AP does not 'normalise' the image - it just applies some default values to it.

Neither of these layers has a colour mode assigned - the colour mode picker display is always 'blank'. See the images below.
If you then assign a colour mode (eg, RGB), the default adjustment values are reset.

So - I have 4 questions :-

1. Why is there no default colour mode assigned to these adjustment layers when creating a new stack ?

2. How are the default values chosen for these adjustment layers ?

3. Why are the default values reset if you select a colour mode ?

4. Why do FITS open with a terrible muddy red/green cast on AP, when they appear as a much crisper neutral grey in other image editors ?
(FYI - The debayer setting is correct, and the colour space used in AP is the same as the source image).
See the example images below.

 

Gary
=====

Default adjustments layers - note there is no colour mode set.

Affinity Photo : Unstacked FITS file                       Other Image Editor : Unstacked FITS file
  

=====

[stokerg]

On 10/7/2021 at 1:04 AM, Gary.JONES said:

1. Why is there no default colour mode assigned to these adjustment layers when creating a new stack ?

 

These adjustments will work to the colour mode of the document, which should be RGB.  By default when you call the adjustments up, they are set to Master, which means all channels.

On 10/7/2021 at 1:04 AM, Gary.JONES said:

2. How are the default values chosen for these adjustment layers ?

 

These are generated from the images supplied for the Astrophotography stack.  So should be different with each set of images.

 

On 10/7/2021 at 1:04 AM, Gary.JONES said:

3. Why are the default values reset if you select a colour mode ?

 

They shouldn't reset, but if you switch from Master to Red, you should then only see the Red channel.  Going back to Master, should show you all of them.

 

On 10/7/2021 at 1:04 AM, Gary.JONES said:

Why do FITS open with a terrible muddy red/green cast on AP, when they appear as a much crisper neutral grey in other image editors ?
(FYI - The debayer setting is correct, and the colour space used in AP is the same as the source image).
See the example images below.

I suspect this will be due to Affinity reading the actual FITS information.  Which other image viewer were you using?  Can you provide the FITS files used in your stack here on the Forums?

[Didge]

Hi Stokerg,

Many thanks for your post - a few comments below.

Cheers,

Gary
=====

1. Why is there no default colour mode assigned to these adjustment layers when creating a new stack ?

These adjustments will work to the colour mode of the document, which should be RGB.  By default when you call the adjustments up, they are set to Master, which means all channels.

Nope.

The document might be set to RGB, but the >>ADJUSTMENT<< layers are not ... they are set to 'nothing'.
Please take a look at the image I attached above - mode ='', channel = 'master'.

The adjustment layer should be set to the same as the document= RGB in this case - but it is not.

Have you tested this ?

=====

2. How are the default values chosen for these adjustment layers ?

These are generated from the images supplied for the Astrophotography stack.  So should be different with each set of images.

Nope.

They are exactly the same for every image. When you select a colour mode in the adjustment layer, they are all reset - this should not happen.

Have you tested this ?

=====

3. Why are the default values reset if you select a colour mode ?

They shouldn't reset, but if you switch from Master to Red, you should then only see the Red channel.  Going back to Master, should show you all of them.

Nope.

Please read my notes above - we need something more than saying they 'shouldn't' reset, when they actually do.

Have you tested this ?

=====

4. Why do FITS open with a terrible muddy red/green cast on AP, when they appear as a much crisper neutral grey in other image editors ?
(FYI - The debayer setting is correct, and the colour space used in AP is the same as the source image).
See the example images below.

I suspect this will be due to Affinity reading the actual FITS information.  Which other image viewer were you using?  Can you provide the FITS files used in your stack here on the Forums?

Hmmm ...

I actually suspect it's because AP is NOT reading the image metadata (FYI - the image profile is not in the FITS metadata. info.

My images already include an Adobe RGB (1988) profile - but AP opens the doc with a message saying 'AP has assigned your working profile (Adobe RGB (1988) to this UNprofiled document.' >> This tells me that AP is not reading the profile information correctly.

In any case, as AP seems to be trying to assign the same profile that is already assigned to the image, so it should still display the colours correctly.

In any case, a mismatched profile would not account for the massive colour bias seen in my images - if I assign any of the other available profiles, the change in colour is very minimal.

 Have you tested this ? 

I'm using Graphic Converter as a comparison :-

Graphic Converter                                                           Affinity Photo
 

FITS files are 32.5MB - I've put one on Dropbox for you here.

=====
iMac 27" Retina - OS 10.14.6
AP 1.10.2.260
=====

[Didge]

Would be good to get a response on this ...

To be effective building Astronomy stacks, AP needs to be able to assign levels and curves properly, and to normalise the images correctly.

Can someone please follow up on this ?

Gary

[James Ritson]

@Gary.JONES hope this helps:

On 10/7/2021 at 1:04 AM, Gary.JONES said:

1. Why is there no default colour mode assigned to these adjustment layers when creating a new stack ?

FIT files and documents created via the Astrophotography Stack Persona are in RGB/32, which is a linear colour space operating with unbounded float pixel values. It's a UI issue, but there's no colour space model on the Curves, Levels and Channel Mixer dialogs for this format, which is why they appear blank. If you purposefully switch to one of the provided colour models, this will reset the adjustment parameters and will also operate in a bounded format, which you will want to avoid. Just leave the adjustments as-is.

On 10/13/2021 at 12:02 AM, Gary.JONES said:

Nope.

They are exactly the same for every image. When you select a colour mode in the adjustment layer, they are all reset - this should not happen.

Have you tested this ?

They are not the same for every image: the gamma value will likely be some median based on an arbitrary scale to perform the non-linear stretching. On a monochrome stack of blue data, I've had a value of 0.582—another stack where I've added LRGB data simultaneously has resulted in 0.651.

The initial Levels and Curves adjustments are just a convenient initial tone stretch, you don't have to use them if you prefer to perform your own tone stretching, perhaps using a different method (e.g. colour preserving tone stretch).

On 10/7/2021 at 1:04 AM, Gary.JONES said:

3. Why are the default values reset if you select a colour mode ?

Because you are switching colour model—e.g. the most common use case is for manipulating tones using LAB/CMYK whilst still in an RGB document and vice versa. There is no feasible way to translate parameter values from one model to another, so they are reset instead. As mentioned above though, there is no need to do this for your workflow.

On 10/7/2021 at 1:04 AM, Gary.JONES said:

4. Why do FITS open with a terrible muddy red/green cast on AP, when they appear as a much crisper neutral grey in other image editors ?
(FYI - The debayer setting is correct, and the colour space used in AP is the same as the source image).

Could be a number of factors. Photo will debayer using an inferred pattern from the FIT metadata (the file you provided is RGGB). There is no colour profile information in the metadata according to ExifTool, so Photo will then have to assign your working space, which presumably you have changed to Adobe RGB in Preferences>Colour?

Regardless of the FIT file's bit depth (yours appears to be 16-bit), it will translate the values to unbounded floats in 32-bit linear. The values in the FIT file should already be linear anyway.

In terms of white balance, there is nothing mandated in the FIT data. When performing the colour space conversion and white point mapping, Photo will likely be using a D65 white point. I'll check this. The initial colour cast that is revealed when tone stretching is fortunately straightforward to neutralise or remove, however.

As far as a muddy or red/green cast, I tried your FIT file in Graphic Converter and got this:

Photo will not match this initially, since this result has been significantly tone stretched, but the red bias is present with both applications if I do some additional stretching in Photo:

So I'm not really sure what to say here. I've never noticed any particular issue with Photo displaying tendency to bias colour data any more than other applications... how did you produce the two previews in your second post?

Just to clarify, you mention that your FIT images should be tagged with the Adobe RGB colour space. I've not used this model of ZWO astro camera, is that an in-camera option?

10 hours ago, Gary.JONES said:

To be effective building Astronomy stacks, AP needs to be able to assign levels and curves properly, and to normalise the images correctly.

Noted—however, it's hardly unusable as-is. I've been using it since it was introduced in the 1.9 beta builds and have thrown all manner of data at it. We've just worked through any roadblocks as they've come up. There are a variety of methods for neutralising colour biases, balancing monochrome data and removing background colour casts, have you tried watching any of the video tutorials on the official Photo YouTube channel or website?

Thanks,
James

[Didge]

Hey James,

Many thanks for your detailed reply ...

I'll respond to each one here ...

5 minutes ago, James Ritson said:

On 10/7/2021 at 11:04 AM, Gary.JONES said:

1. Why is there no default colour mode assigned to these adjustment layers when creating a new stack ?

FIT files and documents created via the Astrophotography Stack Persona are in RGB/32, which is a linear colour space operating with unbounded float pixel values. It's a UI issue, but there's no colour space model on the Curves, Levels and Channel Mixer dialogs for this format, which is why they appear blank. If you purposefully switch to one of the provided colour models, this will reset the adjustment parameters and will also operate in a bounded format, which you will want to avoid. Just leave the adjustments as-is.

RGB/32 (aka RGBA) is a 32 bit colour format where every pixel has three 8-bit RGB values + an additional byte for the alpha (transparency) value.
The Curves and Levels tools (and others) in AP facilitate adjustments to R, G, B and A, so they must be RGBA - so I dont understand what is meant by saying there is no colour model for this - or why AP doesnt assign the RGBA colour model to new (RGBA) images ??

18 minutes ago, James Ritson said:

On 10/13/2021 at 10:02 AM, Gary.JONES said:

Nope.
They are exactly the same for every image. When you select a colour mode in the adjustment layer, they are all reset - this should not happen.
Have you tested this ?

They are not the same for every image: the gamma value will likely be some median based on an arbitrary scale to perform the non-linear stretching. On a monochrome stack of blue data, I've had a value of 0.582—another stack where I've added LRGB data simultaneously has resulted in 0.651.

The initial Levels and Curves adjustments are just a convenient initial tone stretch, you don't have to use them if you prefer to perform your own tone stretching, perhaps using a different method (e.g. colour preserving tone stretch).

OK - I should have tested on a wider variety of images - they are identical for FITS in the same imaging session - as I suppose you'd expect.

IMHO the initial stretches are not right - they should be more neutral than they actually are.

31 minutes ago, James Ritson said:

On 10/7/2021 at 11:04 AM, Gary.JONES said:

3. Why are the default values reset if you select a colour mode ?

Because you are switching colour model—e.g. the most common use case is for manipulating tones using LAB/CMYK whilst still in an RGB document and vice versa. There is no feasible way to translate parameter values from one model to another, so they are reset instead. As mentioned above though, there is no need to do this for your workflow.

I still dont understand this - ref #1

32 minutes ago, James Ritson said:

On 10/7/2021 at 11:04 AM, Gary.JONES said:

4. Why do FITS open with a terrible muddy red/green cast on AP, when they appear as a much crisper neutral grey in other image editors ?
(FYI - The debayer setting is correct, and the colour space used in AP is the same as the source image).

Could be a number of factors. Photo will debayer using an inferred pattern from the FIT metadata (the file you provided is RGGB). There is no colour profile information in the metadata according to ExifTool, so Photo will then have to assign your working space, which presumably you have changed to Adobe RGB in Preferences>Colour?

Regardless of the FIT file's bit depth (yours appears to be 16-bit), it will translate the values to unbounded floats in 32-bit linear. The values in the FIT file should already be linear anyway.

In terms of white balance, there is nothing mandated in the FIT data. When performing the colour space conversion and white point mapping, Photo will likely be using a D65 white point. I'll check this. The initial colour cast that is revealed when tone stretching is fortunately straightforward to neutralise or remove, however.

Yes, AP uses the inferred pattern - there is no way to set RGGB (or any mode) as the default.

And yes, the original FITS contains no colour profile, Adobe RGB (1988) is set as the default in AP.

And yes, the original FITS are 16-bit.

I presume that the RAW option in the Stack persona of 'White Balance = Daylight' is D6500 - but would be good to confirm.

I also presume that 'White Balance = Camera' would not change anything if the FITS file doesnt include a WB profile.

In any case, 'Daylight' really has no meaning for an astroimage.

Also, if there is no WB profile in the FITS file, then AP should not offer 'Camera' as an option. Ditto if there is no 'Master Flat'.

51 minutes ago, James Ritson said:

As far as a muddy or red/green cast, I tried your FIT file in Graphic Converter and got this:

> IMAGE

Photo will not match this initially, since this result has been significantly tone stretched, but the red bias is present with both applications if I do some additional stretching in Photo:

> IMAGE

So I'm not really sure what to say here. I've never noticed any particular issue with Photo displaying tendency to bias colour data any more than other applications... how did you produce the two previews in your second post?

Just to clarify, you mention that your FIT images should be tagged with the Adobe RGB colour space. I've not used this model of ZWO astro camera, is that an in-camera option?

Hmmmm - how did you open that FIT in GC ?

Did you stretch it ??

If you open the FIT and then select Effect/Mathematical/Normalise, you should get an image like the ones I posted above - with a neutral grey.

Apologies - the FITS does not have an RGB profile - I was reading the EXIF data in GC and forgot that GC assigned Adobe RGB (1988) when opening unprofiled images.

56 minutes ago, James Ritson said:

11 hours ago, Gary.JONES said:

To be effective building Astronomy stacks, AP needs to be able to assign levels and curves properly, and to normalise the images correctly.

Noted—however, it's hardly unusable as-is. I've been using it since it was introduced in the 1.9 beta builds and have thrown all manner of data at it. We've just worked through any roadblocks as they've come up. There are a variety of methods for neutralising colour biases, balancing monochrome data and removing background colour casts, have you tried watching any of the video tutorials on the official Photo YouTube channel or website?

Yes, Ive been doing this for a long time too - and really like the power of AP (I also vow never to buy another Adobe product because I refuse to pay recurring fees).

The FITS do have a red bias on images where a UHC filter is used, BUT - the red bias is not what I expect if the app does a default normalisation - I expect to see a neutral colour bias like the one generated by GC - also the detail seems a lot sharper in the GC images. I use the 'Remove Background' filter and wind the grey down to zero, but that doesn't work nearly as well as normalising the image in GC.

And yes, Ive watched all the AP tutorials - they are very good.

So - overall - what Id like to see is a simpler / better implementation of a default normalisation in AP

Gary

[R C-R]

8 hours ago, Gary.JONES said:

RGB/32 (aka RGBA) is a 32 bit colour format where every pixel has three 8-bit RGB values + an additional byte for the alpha (transparency) value.

I could be wrong, but I think James is referring to what in Affinity is named "RGB/32 (HDR)." That format stores each of the color values as an unbounded 32 bit floating point number. See for example the "What is an HDR image?" section of https://www.hdrsoft.com/resources/dri.html for more about that.

Also, there is the help topic https://affinity.help/photo/en-US.lproj/pages/HDR/hdr_editing.html to refer to.

[Didge]

4 hours ago, R C-R said:

13 hours ago, Gary.JONES said:

RGB/32 (aka RGBA) is a 32 bit colour format where every pixel has three 8-bit RGB values + an additional byte for the alpha (transparency) value.

I could be wrong, but I think James is referring to what in Affinity is named "RGB/32 (HDR)." That format stores each of the color values as an unbounded 32 bit floating point number. See for example the "What is an HDR image?" section of https://www.hdrsoft.com/resources/dri.html for more about that.

Also, there is the help topic https://affinity.help/photo/en-US.lproj/pages/HDR/hdr_editing.html to refer to.

Thanks R C-R,

Yes, I suspect you are right - but that applies only if HDR is enabled.

The idea here is that unbounded ICC profile conversions eliminate interim clipping, freeing the result from color space encoding limitations. When using linear gamma profiles at 32-bit floating point precision, there is no gamut clipping even when the image color gamut exceeds the color gamut of the destination color space.

For example, if you converted an image from say, an sRGB camera profile to LAB, then to XYZ then to sRGB for output, in bounded mode, clipping would happen at every step along the way whenever the resulting RGB, LAB, or XYZ values exceed any of these intermediate color spaces' respective encoding ranges. In unbounded mode this "intermediate color space clipping" doesn't happen.

Unbounded mode can take two forms :-

In the 'vanilla' case, values less than zero and greater than one are carried from one ICC profile conversion to the next and clipping is postponed until the point at which the RGB image is output in a file format that doesn't support negative values or values greater than 1 (eg jpegs, pngs, and 8-bit and 16-bit integer tiffs). However, if the following three conditions are met, then the RGB values aren't clipped at all: 

• The ICC profile conversions are done at 32-bit floating point precision.

• The ICC profiles that are used have true linear gamma curve TRCs (Tone Reproduction Curves).

• The RGB image is output in a format that does support floating point RGB channel values that are 0.0 and greater than 1.0 (eg PFM, OpenEXR, and floating point tiffs).

But - I dont think any of this applies to the issues I've described above, because they are not specific to HDR mode - which I havent used - unless I'm missing something /:o

Gary

 

[Didge]

Also, here is another comparison of a FITS image normalised by Affinity Photo vs ZWO ASIFITSView vs Graphic Converter ...

Affinity Photo                                            ZWO ASIStudio / FITS Viewer                  Graphic Converter
  

Each of these images in obtained by opening the same FITS file :-

Affinity Photo : Uses the default Levels and Curves settings as determined by AP

ASI FitsView : Uses ZWO's default normalisation method

Graphic Converter :  uses the Effect/Mathematical/Normalise function.

Clearly, Graphic Converter gives the best result, with a neutral colour bias and low noise.

I want to see a result like the GC image when AP opens a FITS file

[Didge]

Also, here are the results from stacking the same 75 FITS images in AP vs ASI DeepStack, using the default settings for each app,
along with the histogram for each image :-

Affinity Photo                                            ASI DeepStack  
 

    

The histogram for FItsViewer is much more helpful because it has a scale, and its easier to change the x-axis scaling.

AP really needs a log scale for the histogram and also for the adjustment tools.

[James Ritson]

Hi again Gary,

21 hours ago, Gary.JONES said:

RGB/32 (aka RGBA) is a 32 bit colour format where every pixel has three 8-bit RGB values + an additional byte for the alpha (transparency) value.
The Curves and Levels tools (and others) in AP facilitate adjustments to R, G, B and A, so they must be RGBA - so I dont understand what is meant by saying there is no colour model for this - or why AP doesnt assign the RGBA colour model to new (RGBA) images ??

Sorry for the confusion, I'm referring to Affinity Photo's RGB/32 format which is 32-bit per channel. It composites in a linear colour space and supports unbounded pixel values (e.g greater/less than the 0-1 range). The Curves, Levels and Channel Mixer adjustments have the feature you've discovered whereby you can operate in a different colour model whilst the document remains in its source format (with a relative cost in performance due to the realtime colour space conversion). The RGB entry for this only applies to the bounded 8-bit and 16-bit RGB formats, not 32-bit unbounded linear. That's why I said it's a UI oversight: at the moment, if you add one of these adjustments in 32-bit, the colour model dropdown doesn't have an entry for this format—and it wouldn't make sense to expose it for typical bounded formats which most people will be working in.

8 hours ago, Gary.JONES said:

Yes, I suspect you are right - but that applies only if HDR is enabled.

 

8 hours ago, Gary.JONES said:

But - I dont think any of this applies to the issues I've described above, because they are not specific to HDR mode - which I havent used - unless I'm missing something /:o

RGB/32 enables HDR/EDR compositing, certainly, but using HDR is not a requirement. You can composite in 32-bit per channel precision to take advantage of the other benefits: increased precision/resolution, linear compositing, lossless colour profile conversions etc. You've been in 32-bit every time you open a FIT file or perform an astrophotography stack, and nearly all filters and adjustments will work in this format, so unless your machine is struggling performance-wise there is no need to flatten and convert to 16-bit.

[Didge]

Hi James,

Many thanks - that (mostly) makes sense - I think.

But it doesn't help me understand why FITS open in AP with a horrible muddy appearance, when they open in other apps with a nice, crisp neutral colour balance, as in the examples above. I know this can be manually fixed, but it means additional processing steps, and Im not sure AP is giving the same image quality as Im getting with other stackers/editors.

Also - just hilighting my comment above ...
Also, if there is no WB profile in the FITS file, then AP should not offer 'Camera' as an option. Ditto if there is no 'Master Flat'.

And finally, re the UI oversight - hopefully this will be fixed in the next beta 

Gary

[Didge]

Hi James,

Would appreciate if you can follow up on this issue with AP image normalisation  ?