Image Processing with data of type single

Hi,

I need your help in this issue. I have an image(X) with data type 'single'. When I am trying to add noise to this image using "imnoise"(say J = imnoise(X,'salt & pepper',0.5);), my output(noise corrupted) image(J) is loosing the all the decimal components(well the name of the data type is still single, but it looses all the decimal parts of the data) and data is getting rounded to 0's and 1's.

Is there any way that I can add noise to the image and can still preserve the decimal part, so that I do not loose any information?.

Kindly help me out.

Thanks in advance.

[Ashutosh Prasad]

If you are converting the image to 'single' from 'uint8', try doing that using the im2single function.

imag = imread('image.jpg');
X = im2single(imag);
J = imnoise(X,'salt & pepper',0.5);

[Sai Prakash Reddy Konda]

Hello Ashutosh,

I am not converting from uint8 to single. My image it self is in single. When I am adding noise to this image in single, image is loosing its decimal component and getting converted into binary format.

[Walter Roberson]

How do you know that the image() is getting converted to integer?

[L C]

May be the range of the input image X is not in [0 1].

You can do this X = X/255;

or

X = im2single(X);

Answer 1

[Bjorn Gustavsson]

For sake of simplicity - convert every image to double if you possibly can memory-wise. That way you won't have to deal with obscure implicit typecastings and other numerical issues (integer divisions ,ffts on and on...).

HTH

Answer 2

[Guillaume]

Despite your statement, at some point, the image must have been converted from integer type to single, and the conversion wasn't done properly.

When images are of type single or double matlab expects that the intensities are in the range [0-1]. Anything above 1 is the same as 1 as far as matlab is concerned. So if you were to convert a uint8 image whose range is [0-255] to single naively with single(), the original range would be preserved and for matlab intensity [1-254] would all be the same: 1. The proper way to convert an image to single is with im2single() which will divide the intensities by 255 (for uint8 images) to get the right range.

Indeed, if you apply imnoise to a single image whose intensities are integer in the range [0-255], you'll just get 0s and 1s in your output.

The best solution to your problem is to go back to your code, find where this incorrect conversion occurs and fix it. A workaround is to rescale the intensities yourself. Assuming that the intensity range of your single image is [0-255] (the most common, but check yourself with min and max), then:

X = X/255;  %make sure range of intensity is [0-1]
J = imnoise(X,'salt & pepper',0.5)

[Bjorn Gustavsson]

Nah, that is just not true. (Admittedly it is very common, but not all images are necessarily in integer format, have a look at the standar for the Fits-format - look for the interpretation of BITPIX). So the original poster might have an image that properly are read as an image in single-precision real numbers.

The real problem here is all the implicit assumptions done in different matlab-functions.

[Guillaume]

What is not true? I've never said that images are alway integer. I'm perfectly aware that some image formats use floating point. I've even reported matlab bugs about it.

However, it is very likely that the OP image started as integer, and most likely as uint8 as that's the most common. It's very easy to reproduce the OP problem, if you start with an integer image:

X = randi([0 255], 200, 200, 'uint8');  %uint8 image
X = single(X);   %convert to single, should have used im2single to avoid problems
J = imnoise(X,'salt & pepper',0.5)  %result in array of 0s and 1s only

The assumption that matlab makes are documented and are fairly standard. However, I've complained to mathworks in the past that it wasn't visible enough. The assumption is the same for all matlab image processing functions. You do need assumptions or you would have to specify the intensity range in every single function (e.g. with imnoise you'd have to specify what the minimum and maximum value of the noise could be).

[Bjorn Gustavsson]

"Despite your statement, at some point, the image must have been converted from integer type to single, and the conversion wasn't done properly." is not true, is it?

No doubt the behaviour is documented - and perhaps even standard, but from my field where we have images where the pixel intensities are photon-counts the notion that standard image intensities are 0-255 if in integer type or between 0 and 1 if double are repulsively confusing. At the most 255 photons? somewhere between zero and one photon? (and no, intensity scaling is not a great way around that either - just because of the expected noise characteristics...)

[Guillaume]

Again, the majority of images that people asking questions here would be png, jpg, bmp or similar. The majority of the time, these image formats use 8-bit storage (you don't even have a choice with bmp) and a straighforward conversion to single is the most likely reason for the OP problem. And certainly, if he/she wants to use imnoise, the image will have to be in the range 0-1 for the code to work.

"the notion that standard image intensities are 0-255 if in integer type [...] are repulsively confusing". I don't get you there, you can't store more than 255 values as a 8-bit integer.

There are plenty of functions in the image processing toolboxes that don't care about the range of intensity of your image and will work regardless of what your image represents (photon count, temperature, for me fuel concentration) . Others, such as imnoise must know by necessity what the intensity range of the image is, particularly for the salt and pepper option. So, you either need a convention or you need to specify that range for each call of the function. Mathworks have chosen to use a convention. For integer types, that range is the min-max of that type. For floating point, the range is 0-1 as using the full range wouldn't make much sense.

On the other hand I do agree that the documentation of the image processing toolbox is sometimes lacking. I've raised plenty of service requests about it and have sometimes manage to get it improved. imnoise for example clearly documents what happens to the intensities for every noise method except salt and pepper. I also agree that sometimes the convention it adopts are not well thought out. For example, what drives me up the wall is this split personality the toolbox has with regards to coordinates. Some functions use standard matlab row, column coordinates others use x,y (column, row).

[Bjorn Gustavsson]

True, the majority will be such images, and therein lies "des pudels kern".

In addition to 8-bit integers there are 16-bit integers and some standard image formats (tiff) allow that and FITS allows 32 and 64 bit int as well.

On you other points I completely agree - the image processing toolbox seems to have "two parrents" or a bit of a "split personality", and perhaps that is understandable though not preferable.

[Guillaume]

For info, I've submitted an enhancement request for the documentation of imnoise so that it details the image requirements for the 'salt & pepper' option, the same way it does for all the other options.