Please come all to AstroFest in London to ask us (Mabula & Vincent) questions and to see live demos of APP!
2023-01-19: APP 2.0.0-beta13 has been released !
!!! Big performance increase due to optimizations in integration !!!
and upgraded development platform to GraalVM 22.3 based on openJDK19
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Muted Colors in APP
since using APP for stacking I am unable to get proper color results (this is not just a 1.080 issue). In general, saturated Colors show unsaturated, while unsaturated colors change their Hue. I tried stacking with both Background Neutralization On/Off with basically the same results. I am just unable to obtain any meaningful result from this, because cranking up saturation will shift unsaturated colors literally into nirvana.:-)
To get to the bottom of this, I took a shot of a color checker, stacked just one single light (with the same results) and compared to DXO (my general photography Raw converter) and the result is much better here. I agree it's not exactly scientific approach, but demonstrated the effects very clearly
What can be seen in APP, is red saturation showing quite OK, while the green channel comes clearly muted (unsaturated) and Blue is almost non existent, drowning in all other colors "errors". Hence, blue turns into violet which explains the poor results I received on M45 stacks for example. Overall, all colors show a muddy, grey "haze" and look darker. Very low B and G values are reproduced too high and very high values reproduced too low. Stretching strongly will make this even worse as the "Grey" will be cranked up visually, not the colors.
What can I do to improve this? I have attached a screencopy of my test results, hope the effects are visible properly
Interesting. It would help if you could graph those tables.
Immediately I wondered if APP is properly applying the colour conversion matrix (CCM) provided in the RAW files - it adjusts for colour overlap in the RGB filters. I noticed that sometimes Astro software ignores this conversion if the forward CCM is not given. However I believe APP is using open source raw converters that should be working properly but maybe they aren't. I'm not a big fan of open source. I complained to Siril about this once and they just said its just colour balance - I don't think they new what the colour conversion matrix was - of course the colour matrix is part of colour balance!
I rather consider a bug in the demosaicing too, because red and blue channels seem to behave differently. It seems R receives much more crosstalk from G and B than Red does receive from G and B. As I said, just a suspicion. BTW I tried both bilinear and Adaptive Airy Disk Algorithms and they do not seem to make much difference.
@Astrogee: will try to spare some time to graph those. pls allow me a day or two 🙂
I would be surprised if this is indeed an issue as I’ve not seen many differences in processing. I did see an improvement even in accurate color reproduction as can be seen in the release notes for 1.080. Mabula should be able to check this and explain though, always good to see if there indeed is an issue or not, so thanks for reporting!
Thank you very much for your investigation. I think I can explain everything that you are seeing at the moment with your test and can confirm that I am working to have this fixed for RAW data from consumer camera's.
First of all, what you are comparing in this case at the moment is apples to oranges and I will explain why 😉
You are comparing non-linear sRGB/Adobe1998 frames with Color Checker and DXO lab to APP's linear raw conversion which is then stretched with APP's preview filter. These are very different outcomes as you would expect, really.
APP, currently does not use the camera model matrix and is also not applying the sRGB / AdobeRGB S-curve. You can apply camera White Balance with APP, but not yet the camera matrix and S-curve, the S-curve makes it non-linear.
To get from linear raw data to the non-linear sRGB/Adobe1998 colors the following needs to happen:
- black offset is subtracted
- camera white balance is applied
- camera model matrix is applied
- s-curve for sRGB/Adobe1998 is applied
Now in data processing in APP, these last 2 steps are not possible yet and therefore you get what you are seeing in your test.
But.... APP can show you the non-linear sRGB/Adobe1998 data though, to demonstrate that the technology is already in APP and I just need to implement it now for actual data processing. The image viewer mode has the setting image. This can be found in the dropdown box above the image viewer window.
Let me demonstrate it with a nice colorchecker image of a Sony RX1 arw frame:
I set the DDP preset on the right side, to no stretch (data as is). In that way, I am excluding the effect of APP's preview filter stretch on colors.
The image viewer mode is set to the default linear value and camera white balance is not enabled in 0) RAW/FITS :
This is unstretched linear raw sensor data of the raw frame. So this is the pure raw data 🙂 !
Let's look at this with the auto-stretch of the preview filter:
So, currently, APP uses this in data processing of your raw frames. Camera White Balance, the Camera Model Matrix and the s-curve conversion are all three not applied.
Now, let's look what happens if I enable Camera White Balance in 0) RAW/FITS and I reload the image still with the linear image viewer mode:
This is now linear raw sensor data with Camera White Balance applied and then autostretched with the preview filter. Already looks better, right?
Now, the next step is what is currently missing in APP's data processing but can be shown with the image viewer mode: image
Step 1) disable the autostretch again:
Linear Camera White Balance data without stretch
Step 2) change the image viewer mode (above the image viewer window) from linear to image :
This is now the wanted non-linear sRGB data, Camera White Balance + Camera Model Matrix + S-curve conversion are all applied ! (And no auto-stretch from the preview filter)
This is the data that you want to compare in your test with the colorchecker and DXO lab test results 😉 because this will soon be used in data processing in APP.
Let's put it all in 1 image to see the differences:
Now for going forward with APP: both the camera model matrix and the s-curve conversion are currently missing for processing. They both have influence on the colors, so the s-curve has influence as well. APP's preview filter works differently than the s-curve, it indeed flattens the colors. To solve this, I will soon implement color-preserving stretching so the linear color ratio's are preserved. And soon, I will make it possible for the user that you can apply the camera model matrix as well for processing 😉
I hope this clarifies a lot about raw processing in APP in it's current state. With this state, you can still get good Star Color Calibration on Raw data from consumer camera's.
But to get initial better color reproduction form consumer camera raw files I need to and will implement:
- allow the camera model matrix to be used in raw data processing in APP
- allow the s-curve conversion and/or implement color-preserving stretching in the preview filter.
Let me know if you have any question about all of this, I will soon make these improvements 😉
thanks for the explanation and clarification. I am aware and you are fully right comparing apples to oranges. I just wanted to demonstrate it was possible to get decent colors out of the existing RAW. Developing APP stacks I had issues to produce decent color ranges in the images, which was really a pity because APP is such a great software.
While my Post-Prod software (StarTools) is able to apply the camera Matrix, this did not help along with the muddy pinkish blue tones. Cranking up saturation also didn't help because fully saturated colors and pastel colors just produced the same RGB values in the stack. Whatever is adjusted will be wrong for either color.
I think color preserving stretching will surely make a difference. Any way of reducing the "channel crosstalk" will help to do the remaining tuning with standard tools like saturation and white balance controls. Glad to hear this will improve soon 👍
Hi Mabula, I saw this topic on using S-curves to enhance RAW images before stacking. I saw what I think is a similar stack process on Clark Vision's site... https://clarkvision.com/articles/image-stacking-methods/
In their article the best result was "Sigma-Clipped average combine on tone-mapped data". I'm thinking the tone-mapped data is an S-curve conversion. I would love to hear your thoughts. Also, as the improvements you discussed in this topic been implemented in APP yet?
Hi Tim, @tstevens83,
The changes are not yet implemented, but are still on the ToDo list. This is by no means a trivial task to be clear so it will take a bit of time before this can be released properly.
An S-curve conversion applying to data before stacking does give a lot of problems and you will certainly lose flexibility in data processing, because the data will no longer be linear... this then means that any statistical calculation on the data, like for data normalization or the pixel outlier rejection will always be skewed and it will work less optimal as a consequence... so it has serious downsides as well, which I would like to solve as part of this implementation 😉