0
$\begingroup$

I have two FLIR Blackfly cameras that are identical outside of one being color and the other being mono. I set the ADC of both to 10 bit, and save the images in 16 bit. This results in the combed histograms shown below (or at least I believe this is the cause...). The strangest bit is how the different color channels are interleaved where they overlap. Is there a way to mitigate and/or prevent this issue?

Mono

Color

enter image description here

Edit:

Including a sample image and corresponding histogram (channel 2). Note, the image had to be cropped and limited to a single channel to fit within data size constraints.

poster

enter image description here

Improve this question
$\endgroup$
2
  • $\begingroup$ You are probably not separating the channels and what you see on the bottom is the "overlay" of three histograms on the same graph. $\endgroup$
    – A_A
    Jun 1, 2020 at 14:38
  • $\begingroup$ Yes, they're not separated. Doesn't really address the issue. $\endgroup$
    – B. Erickson
    Jun 1, 2020 at 15:19

1 Answer 1

Reset to default
1
$\begingroup$

This might be hardware / software specific.

You can reproduce this kind of artifact with a "simple window" that tries to map a narrow range of the original scale to a wider range. Each individual pixel is described by an integer, which, once it goes through the linear mapping transformation gets transposed to a different bin.

An extreme example would be trying to map the range 0..1 to the range 0..7 with both ranges originating from natural numbers. There is nothing else in the range 0..1 except 0 and 1. Consequently, there is nothing to map to 1,2,3,4,5,6. If you tried to map 0..3 to 0..99, you would again only fill 4 bins of the wide range.

You can "simulate" this condition over any image by trying a similar narrow->wide mapping:

enter image description here

What happens in your case is that the software (or your code) sees the full range as 16bit (65536 bins) but this 16bit range describes a much narrower 10bit (1024 values) range. What you see are the steps of this "re-quantisation".

The RGB image without any concern to the fact that there are three different histograms depicted does not show any overlap or interleaving. It is the same condition described above but the data from the three histograms do not have to "sit" exactly in the same values because they describe colours. If they did sit on exactly the same values, then the image would appear in grayscale (even if it had three channels).

If you don't like these bins, then simply re-map the values to a narrower range. There will not be any loss from this.

The point about this being hardware/software specific is that, depending on the application, the camera (or any libraries used by the camera or yourself) might be taking decisions that cannot be changed (e.g. re-map the 10bit values to 16bit values without being able to override or perform specific measurements and serve a ready made value). And in that case, more data would be needed to decide how to apply any further "correction" properly.

Hope this helps.

Improve this answer
$\endgroup$
14
  • $\begingroup$ Would one solution be to convolve with a filter such a a Gaussian filter to blend/fill-in the otherwise larger gaps between levels? $\endgroup$
    – Dan Boschen
    Jun 2, 2020 at 16:15
  • $\begingroup$ @DanBoschen It depends on the application. This would interpolate the gaps and make the graph (as a curve) look good. But what information do the inteprolated values carry? The "explanation" of the histogram is that if you take one of its bars, it tells you how many pixels in the image are set to the shade the bar represents. An interpolated bar, would report "ghost" pixels. These pixels do not exist in the image. A 10bit histogram is smooth enough for plotting purposes (if you plot it as a 10bit histogram). $\endgroup$
    – A_A
    Jun 2, 2020 at 16:36
  • $\begingroup$ I see—- you are suggesting the gaps are likely all in the histogram itself and not in the data; but strange then that the different colors would appear in different buckets of the same histogram unless it was the data? $\endgroup$
    – Dan Boschen
    Jun 2, 2020 at 22:16
  • $\begingroup$ @DanBoschen The "data" is the image. Gaps would appear as some sort of "corruption" easily. For the second observation I am not sure I get what you are saying exactly but to see where I am getting at: Load an RGB image on GIMP and then flick through each channel and look at how the histogram changes. The relative differences in range on each channel is the colour balance. $\endgroup$
    – A_A
    Jun 4, 2020 at 10:10
  • $\begingroup$ I understand the range of each color, I was referring to how one color is filling in different gaps that the other colors leave as gaps. So the image in the end is as if it is quantized with fewer bits (effectively, just interesting that it is not the same quantization for each color); that’s why I was thinking of a Gaussian filter and what it would do to distribute the bins across more values, if that is what the OP wanted. $\endgroup$
    – Dan Boschen
    Jun 4, 2020 at 11:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.