[Sticky] Does astro pixel processor apply the color matrix correction to digital camera raw data?

Hi,

In the RAW tab, APP still shows R;G;B factors all @ 1,0 and there is no indication of the Matrix correction whatsoever. 

Is there a way to unselect the Matrix correction to keep the stack as "raw" as possible?

I would like to apply Matrix correction in my after processing in StarTools.

regards,

jochen

Let me ask Mabula for this specifically, I may be wrong there...

Hi @theo950 & @jochen-scharmann & @vincent-mod,

No, the color matrix is not yet applied in Astro Pixel Processor. It is hardly a trivial task as well, but it will soon be introduced in APP now that we support almost all raw formats in APP using Libraw. Thanks to Libraw and our testing, we now know for all camera models the color matrix and you can actually see that in the latest APP version in the console window when you load a consumer camera RAW frame:

A canon EOS 5DS R CR2:

Jochen, the RGB factors are there so that you can adjust/overrule camera white balance yourself 😉 they have nothing to do with the camera matrix.

Kind regards,

Mabula

Ah there we go, woopsie from my part.

Thanks Mabula,

got it, but once it will be introduced, will there be an option to disable Matrix correction? 

jochen

@mabula-admin "What I would propose to implement in APP is the following: since I have written the raw conversion myself, (APP doesn't rely on DCRAW) I have complete control. I can simply give the user the option to apply color matrix conversion to either sRGB or Adobe 1998 through the XYZ neutral colorspace from the camera/sensor colors, (without applying the last step, the gamma curve). This will happen as a final step in image loading. Data calibration would not be affected because this is done dynamically in the image loaders immediately after having read the sensor colors from the raw file. Off course, the color matrix won't be applied to the calibration frames, only to the lights. This would solve all problems I think that you discuss."

Hi Mabula,

Sorry if I am asking a silly question, but I have been wondering if this is implemented in the latest APP? As before, I still use the ASI 094 OSC camera, which is used by various consumer cameras like the Nikon D810. What I am looking for is an option to get an image from the ASI094 (or whatever DSO camera) that looks 'as if' it were from the equivalent(or similar) consumer camera? So in my case, it would be as if the images were taken with a 'cooled D810', which is essentially what the ASI 094 is (for me anyway)..ie would there be an option to choose the 'DSLR equivalent' Raw conversion forr any given DSO camera sensor? or in other words, I would like to have the ASI094 raw fits files be processed as if these files were from the D810 - is this possible?

Thanks!

😛

Hi all @rudypohlgmail-com & @sharkmelley,

The next APP version 2.0.0-beta15 will finally support data processing using the camera color conversion matrix 🙂 It will convert the sensor data to the Linear RGB color space (so the sRGB/Adobe1998 gamma curve is not applied to keep the data linear). Soon I will publish some results in the new release notes. I expect 2.0.0-beta15 to be released within a couple of days time...

Mabula

@mabula-admin Will there be an option to NOT apply camera Matrix at this point to keep the data as "RAW" as possible?

Posted by: @jochen-scharmann

↑

@mabula-admin Will there be an option to NOT apply camera Matrix at this point to keep the data as "RAW" as possible?

Hi @jochen-scharmann, of course, just like the camera white balance, you will be able to enable/disable it.

to keep the data as "RAW" as possible?

Well if the white balance and the camera matrix is applied, the data is still completely raw and perfectly suitable for data calibration and linear processing. We do not apply the sRGB/Adobe 1998 gamma curve because that would kill that. Instead we convert the sensor data to the Linear RGB color space using both the camera white balance and the camera matrix. Furthermore, the camera matrix is applied after data calibration so it will not hurt that. Old masters are still 100% compatibel. And it also works fine with 32bits masters as well.

I will perform some tests today and will publish these soon to show the difference in results that you will get. Clearly, the colors in the raw data are much better now, that is what I can already say 😉

Mabula

Thanks Mabula,

I understand that it's still linear. My concern is more about individual multipliers, even if linear, as they'd multiply signal as well as noise in all channels unevenly.

Furthermore, while the "Camera Matrix" multipliers are great for daylight photography using a standard DSLR, they would throw off modded cameras. Applying the Matrix on my modded Sony A73 will boost the Reds into horrible territory....

Looking forward to beta 15...

Jochen

Posted by: @jochen-scharmann

↑

Thanks Mabula,

I understand that it's still linear. My concern is more about individual multipliers, even if linear, as they'd multiply signal as well as noise in all channels unevenly.

Furthermore, while the "Camera Matrix" multipliers are great for daylight photography using a standard DSLR, they would throw off modded cameras. Applying the Matrix on my modded Sony A73 will boost the Reds into horrible territory....

Looking forward to beta 15...

Jochen

Sure, I understand 😉 For some data it will work nice, for other data and modded camera's it can be a problem yes.

Mabula

@mabula-admin 

After reading this topic, I got some workflow related questions about how to make the best use of this implementation.

First off, as some of my lenses tend to have some slight chromatic abberations, I do always select „align channels“ after calibration. But as far as I can see, this requires demosaiced/debayered data. (I tend to integrate multisessions on those calibrated files, what does work nicely)

(But) As it is mentioned several times (here and in other topics), the whole integration process works best on raw data. So what is the best approach to cope with misaligned channels, while preserving the benefits of APP (after all your effords and implementations to work on raw data as long as possible)? Maybe align channel after integration?

Furthermore, if I am done integrating and off to post-processing. At which step will it be ok to stop in APP and do some tweaking in other software? 

I tend to do star removal and stretch background and stars seperately, doing some deconvolution right before separation of stars. Is it save to switch to, lets say siril for deconvolution and star seperation, (after LP-removal, background calibration and maybe star color alignment in APP), and then turn back to do the stretching, save stretched files for last tweaking in gimp?

What would be a valid approach. I reaöly do want to benefit of the color preservation discussed here. (Well i am able to stretch color preserving in siril, but do have some issues in doing well.)

Finally I am asking this, because I am still not totally sure when demosaicing/debayering and will "finally" be done and the color matrix applied?

Posted by: @xyfus

↑

@mabula-admin 

After reading this topic, I got some workflow related questions about how to make the best use of this implementation.

 

First off, as some of my lenses tend to have some slight chromatic abberations, I do always select „align channels“ after calibration. But as far as I can see, this requires demosaiced/debayered data. (I tend to integrate multisessions on those calibrated files, what does work nicely)

(But) As it is mentioned several times (here and in other topics), the whole integration process works best on raw data. So what is the best approach to cope with misaligned channels, while preserving the benefits of APP (after all your effords and implementations to work on raw data as long as possible)? Maybe align channel after integration?

 

Furthermore, if I am done integrating and off to post-processing. At which step will it be ok to stop in APP and do some tweaking in other software? 

I tend to do star removal and stretch background and stars seperately, doing some deconvolution right before separation of stars. Is it save to switch to, lets say siril for deconvolution and star seperation, (after LP-removal, background calibration and maybe star color alignment in APP), and then turn back to do the stretching, save stretched files for last tweaking in gimp?

What would be a valid approach. I reaöly do want to benefit of the color preservation discussed here. (Well i am able to stretch color preserving in siril, but do have some issues in doing well.)

 

Finally I am asking this, because I am still not totally sure when demosaicing/debayering and will "finally" be done and the color matrix applied?

Hi @xyfus,

If you suffer from chromatic aberrations, it is best to align channels indeed in 2) Calibrate, it does require the data to be demosaiced, since we need the R,G,B channels to be aligned using the stars, the R and B channels will be aligned using subpixel precision and we simply can not de-demosiac again then.

There is no problem, here, the data after demosaicing is still raw yes, but an option like bayer/X-trans drizzle will not be possible anymore. If you want to use that option, then don't align channels in 2)Calibrate and perform the align channels on the bayer-Drizzled result, which should also work fine.

Furthermore, if I am done integrating and off to post-processing. At which step will it be ok to stop in APP and do some tweaking in other software? 

That is a very difficult question and is very user dependent I think depending on their skill and experience and personal taste perhaps?

I tend to do star removal and stretch background and stars seperately, doing some deconvolution right before separation of stars. Is it save to switch to, lets say siril for deconvolution and star seperation, (after LP-removal, background calibration and maybe star color alignment in APP), and then turn back to do the stretching, save stretched files for last tweaking in gimp?

I guess that will be fine, I see no big problem in such a workflow 😉

The color matrix only applies to consumer camera's like Canon, Nikon, Sony etc... the color matrix gives initial more color saturation in your raw frames. It is applied whenever you load an image, so it is already applied when your images enter 3) Analyse Stars after data calibration. Some holds for demosaicing unless you integrate with Bayer/X-Trans drizzle, then only the CFA pixels of your images will enter the integration, no demosaicing is done. These CFA pixels are converted using the camera color matrix still 😉

Let me know if this answers your questions.

Mabula

Posted by: @mabula-admin

↑

Let me know if this answers your questions.

Thx mabula, you answer is very ok for me to stay with my workflow (some questions remain, but these are not for you to answer)

Posted by: @mabula-admin

↑

There is no problem, here, the data after demosaicing is still raw yes, but an option like bayer/X-trans drizzle will not be possible anymore. If you want to use that option, then don't align channels in 2)Calibrate and perform the align channels on the bayer-Drizzled result, which should also work fine.

Yes, I did try this once, and it looked fine for me! So, this is a valid option, nice to know for the future! 🙂

Posted by: @mabula-admin

↑

 

Furthermore, if I am done integrating and off to post-processing. At which step will it be ok to stop in APP and do some tweaking in other software? 

That is a very difficult question and is very user dependent I think depending on their skill and experience and personal taste perhaps?

My question was aimed about if there is some "harm" (data wise) in switching to early in process.

(Aside that it truly is very subjective and depends on individual preferences, yes.)

But you answered that afterwards:

Posted by: @mabula-admin

↑

I guess that will be fine, I see no big problem in such a workflow 😉

Posted by: @mabula-admin

↑

The color matrix only applies to consumer camera's like Canon, Nikon, Sony etc... the color matrix gives initial more color saturation in your raw frames. It is applied whenever you load an image, so it is already applied when your images enter 3) Analyse Stars after data calibration. Some holds for demosaicing unless you integrate with Bayer/X-Trans drizzle, then only the CFA pixels of your images will enter the integration, no demosaicing is done. These CFA pixels are converted using the camera color matrix still 😉

Yes, I do indeed own a consumer camera Panasonic Lumix GX9, and was very pleased that it is fully supported in APP. I did once some research on the color matrix for using it in rawtherapee. This really does make some difference to color representation.

Thank you for explaining this! So it is implemented as early as step 3. Nice hint about how it is done with bayer drizzle

Finally thank you guys for this wonderful piece of software. Best application for stacking I encountered (and it is doing so much more)! 🙂

Hi Sebatian @xyfus,

Excellent, you are most welcome ! It is our pleasure.

Mabula