`adjust_histogram` not robust to `NaN`

[theogf]

So I know it's a long stretch but I am working on a project where colored images are badly treated. I sometimes run adjust_histogram(img, Equalization()) and it appears that in transform_density, the input img contains NaN value and an error is returned. Then the line index = floor(Int, (val-first_edge)*inv_step_size) + 1 returns an error when isnan(val)

To be honest I don't really know where the NaN values come from.

[zygmuntszpak]

Thanks for raising the issue. Just to clarify, when you say that color images are badly treated, do you mean that you apply adjust_histogram to a color image and for some images it fails because in the process some NaN values are created? Or do you mean, that the colour images has some NaN values to start with?

Would you be able to share an example problematic color image?

[theogf]

I mean that I apply all kinds of filters. The problem is that my process is completely random but I will try to go through the seeds and find one reproducible example.

Sorry that my problem is too vague :sweat_smile:

[zygmuntszpak]

For coloured images, the input is converted to YIQ type and the Y channel is equalised. This is the combined with the I and Q channels and the resulting image converted to the same type as the input

I suspect something is going wrong with conversion to the YIQ space. You could try this out on the results of your filters and see.

What is the final type of the image that you pass in? RGB Float64? Are all the channels in the unit interval?

[theogf]

Hi @zygmuntszpak, Sorry for the delayed answer. I checked again, and using ImageTransformations.jl warp function, I indeed sometimes got some NaN values in my image! I am working indeed in RGB{Float64}

[johnnychen94]

The NaN returned from warp is an deliberate behavior -- it is used to indicate missing regions.

I'm using the phone so can't easily check out the documentation. If my memory serves well, there is a 'fillvalue' or 'fill' keyword for ImageTransformations operation, for which you can pass a, e.g., zero(RGB) or oneunit(RGB)

[theogf]

Oh I would definitely not consider that a bug 😁 that makes total sense to return NaN here. I just wanted to explain where it came from!