handling of saturated pixels in PhotometricMosaic 3.0

pfile

Well-known member
the case that i am looking at might be a bit of a corner case - i was experimenting with Wei-Hao Wang's public dataset of the eta carina nebula, but since i was just playing around i was using DSLR RAW files and letting libRAW debayer them, with highlight clipping turned on. as a result there are saturated pixel values in the stars, and many places where there are only 1 or 2 channels where the pixel data is 1.0. this might be a debayering artifact since you'd expect stars to be fully saturated at the core and then drop off radially but this data does not look like that.

in this case, in the mosaic result from PMM3.0, i am seeing some of these pixels getting set to very low values in the green channel only. the R and B channels seem fine.

a couple of screenshots follow. on the left is the mosaic result (green channel shown) and on the right is the corresponding pane out of MosaicByCoordinates. the 2nd screenshot shows which pixels are saturated and in which channels (given the color of the pixel.) there's clearly a correlation between the partially-saturated pixels and the green channel pixels but it is not a perfect map. the green pixels are fine in the output from MBC, so this is not a registration artifact (but it occurs to me the partially-saturated values might be.)

the two files are actually available on google drive as part of WHW's public release: they are IMGP7198 and IMGP7199 in this folder:


if there is some setting that i'm missing in PMM please let me know. or maybe i should just not be using PMM on images like this?

thanks

rob


Screen Shot 2021-01-16 at 11.15.26 AM.jpg
Screen Shot 2021-01-16 at 11.17.21 AM.jpg
 
the case that i am looking at might be a bit of a corner case - i was experimenting with Wei-Hao Wang's public dataset of the eta carina nebula, but since i was just playing around i was using DSLR RAW files and letting libRAW debayer them, with highlight clipping turned on. as a result there are saturated pixel values in the stars, and many places where there are only 1 or 2 channels where the pixel data is 1.0. this might be a debayering artifact since you'd expect stars to be fully saturated at the core and then drop off radially but this data does not look like that.

in this case, in the mosaic result from PMM3.0, i am seeing some of these pixels getting set to very low values in the green channel only. the R and B channels seem fine.

a couple of screenshots follow. on the left is the mosaic result (green channel shown) and on the right is the corresponding pane out of MosaicByCoordinates. the 2nd screenshot shows which pixels are saturated and in which channels (given the color of the pixel.) there's clearly a correlation between the partially-saturated pixels and the green channel pixels but it is not a perfect map. the green pixels are fine in the output from MBC, so this is not a registration artifact (but it occurs to me the partially-saturated values might be.)

the two files are actually available on google drive as part of WHW's public release: they are IMGP7198 and IMGP7199 in this folder:


if there is some setting that i'm missing in PMM please let me know. or maybe i should just not be using PMM on images like this?

thanks

rob


View attachment 10033
View attachment 10032

Hi Rob
If you could send me a link to two registered files, I will take a look at it for you. Use the XISF format and use compression (the black areas compress really well).
Regards
John Murphy
 
I am unable to reproduce the problem.
Once you have sent me your two registered files, and a ProcessIcon for the PhotometricMosaic settings, I will have another look.

Regards
John Murphy
 
i'll send the files. they are pretty large but i'll try saving with compression (i usually have that turned off.)

edit: as i was saving them i realized they are i16 since they inherited from DSLR raw files. i am surprised that MBC saved them as i16; i would have expected f32. maybe this is related to the problem.
 
Yes, the i16 format might result in overflows that cause bright pixels to turn black. Hence the first thing might be to try converting to floating point before PhotometricMosaic. Let me know if this fixes it.

Regards
John Murphy
 
indeed that is the problem; a conversion to f32 before running PMM yields the expected result. i guess what MBC is doing is probably sane as 99% of the time the image is going come in as f32 or f64 and so preserving the sample format makes sense.

rob
 
Great news.

Also, if the images saturate at, for example, 0.3 instead of 1.0, it may be worth multiplying the images by 1.0 / 0.3 before using PhotometricMosaic. This will then allow samples that contain saturated pixels to be rejected. The photometric 'Linear Range' 0.5 would then not need modifying. Otherwise set this to 0.3 / 2

Regards
John Murphy
 
thanks - yes, with 14-bit DSLR data this "saturated un-saturated" data is always a problem. it would be nice if PI could rescale images as they were calibrated. maybe loading calibrated xisf files with the format hint "normalize" turned on would solve this except hot pixels might throw off the normalization.
 
thanks - yes, with 14-bit DSLR data this "saturated un-saturated" data is always a problem. it would be nice if PI could rescale images as they were calibrated. maybe loading calibrated xisf files with the format hint "normalize" turned on would solve this except hot pixels might throw off the normalization.

Yes, I was thinking along similar lines. My current plan is to look for the maximum value in the image and set that to the internal 'saturated' value instead of using the value 1.0 to reject samples. It might be quite important for DSLR data. I will investigate.

Regards
John Murphy
 
Yes, the i16 format might result in overflows that cause bright pixels to turn black. Hence the first thing might be to try converting to floating point before PhotometricMosaic. Let me know if this fixes it.

Regards
John Murphy
PhotometricMosaic currently creates the new mosaic using the same image format as the target image. The next version will check for integer format. If the target image is integer, the new mosaic will use 32 bit floating point. This fixes the problem

Regards
John Murphy
 
thanks for adding that code. it does seem like a real corner case but sounds like it is not too hard to fix.

on the subject of DSLR 14-bit data... i rarely work with DSLR data but i was looking at another of WHW's datasets. it looks like the right thing happens if you give the format hint "clip-highlights", but this has to be done everywhere a RAW file is going to be read in, that is, when making the calibration masters as well as calibrating the lights and flats. i'm not really sure what this keyword really does but the values in the dark/bias are definitely different with this keyword turned on and off. if i had to guess (which i shouldn't because the libRAW source code is out there) i'd say that it's multiplying the data by 4 and then clipping all 4 pixels in a bayer quad where one or more are clipped in the original quad data.

however - i think the "separate CFA flat scaling factors" is probably slightly changing the saturated values so saturated objects seem to have developed a slight color cast. i am going to repeat with this setting turned off and see what happens.

at any rate i think PCC has this same problem with the true saturation value, and it solves this problem with a slider that lets the user choose what the saturated value is and those stars with any channel above that value are eventually ignored.

rob
 
thanks for adding that code. it does seem like a real corner case but sounds like it is not too hard to fix.

on the subject of DSLR 14-bit data... i rarely work with DSLR data but i was looking at another of WHW's datasets. it looks like the right thing happens if you give the format hint "clip-highlights", but this has to be done everywhere a RAW file is going to be read in, that is, when making the calibration masters as well as calibrating the lights and flats. i'm not really sure what this keyword really does but the values in the dark/bias are definitely different with this keyword turned on and off. if i had to guess (which i shouldn't because the libRAW source code is out there) i'd say that it's multiplying the data by 4 and then clipping all 4 pixels in a bayer quad where one or more are clipped in the original quad data.

however - i think the "separate CFA flat scaling factors" is probably slightly changing the saturated values so saturated objects seem to have developed a slight color cast. i am going to repeat with this setting turned off and see what happens.

at any rate i think PCC has this same problem with the true saturation value, and it solves this problem with a slider that lets the user choose what the saturated value is and those stars with any channel above that value are eventually ignored.

rob
I am thinking of adding a '16 bit camera' check box (defaulting to on). If the camera was not 16 bit, I will look for the highest value in the image when calculating the default linear range. I might also add an extra control in the sample rejection so the user can reject samples that contain saturated values. It would default to the image's maximum value. This way the user will not have to change how they process their data.
Regards
John Murphy
 
i guess since in theory mosaic panes will be "well behaved" images finding the max value would work, but if there are hot pixels and such they might throw off this calculation. it starts to get complicated but probably some statistical analysis of the maximum value would be in order to figure out whether or not the max value is an outlier or truly represents saturated data would be needed...
 
i guess since in theory mosaic panes will be "well behaved" images finding the max value would work, but if there are hot pixels and such they might throw off this calculation. it starts to get complicated but probably some statistical analysis of the maximum value would be in order to figure out whether or not the max value is an outlier or truly represents saturated data would be needed...
You are correct in thinking it gets a bit complicated!

My current thinking is that the hot pixels will be limited by the camera's bit range, just like the star cores. The complications will turn up due to preprocessing - for example, the debayer process and flat field correction.

Fortunately, it is not too critical for the calculated linear range. It is likely to be more of a problem for rejecting samples that contain saturated pixels. The calculated default will be approximate, and in problem cases the user will need to fine tune it. I could set this rejection level slightly below the maximum value - I am still thinking about it, and will experiment...

Regards
John Murphy
 
Back
Top