unit 8 and im2double and white pixel

Can someone tell me what is wrong with my choices? I think the answer can also be option D. However, none of them are showing correct.

[dpb]

Can you not try them out and see, empirically?

But as a hint thinking about it -- the key is to understand the type of the operation taken on the variable -- im2double returns a double, the addition operator returns the type of the operands; text constants are cast to type in context and limited-width integers saturate silently w/o warning.

The message is correct as far as it goes, but it doesn't include the explicit reminder that im2double also returns a double -- which is important because of the first condition in the following sentence

Answer 1

[DGM]

I think it was your comment I responded to earlier, so I suppose there's no harm repeating it here. Tools like imshow() and imwrite() expect image data to be within a certain range which depends on the numeric class of the array. Floating point classes are within [0 1], and integer classes are expected to be within the allowable range of the integer width (e.g. [0 255] for uint8).

So if you have any 'uint8' image, you can be certain that all values are within [0 255], since uint8 simply can't represent values outside that range. When cast and scaled with im2double(), those values must lie within [0 1] due to that prior constraint, but if you add 50 to it, 'double' can certainly represent values outside [0 1]. It's just by convention that MATLAB interprets 0 as black and 1 as white. So now your image contains values in the range [50 51] -- beyond white. The most that can be represented is white, so that's what's displayed.

Similar might happen if you took your uint8 image and created an improperly-scaled floating-point copy by using double() instead of im2double().

Bear in mind the older comment I made in that other thread. See also Walter's comment. The question is a bit misleading, since imshow(), image() and imagesc() will treat such a single-channel image differently than they would treat an RGB image. While image()/imagesc() display single-channel images in pseudocolor using the axes colormap, imshow() uses the gray() colormap. So depending on which tool you use to display the image and what options you select when you call it, you might get white, or you might get some color belonging to the current colormap.

FWIW, I know there's a webdocs page that discusses the subject of class-dependent image data range conventions, but I can't find it. If I can't find a webdocs page that I know exists, I can excuse anyone else for never finding it either.

[Image Analyst]

Jeez, yeah. Maybe we should look over the test and suggest clarifications for ambiguous questions like that. Who made that test?

[DGM]

For what it's worth, until today, I had no idea this was even a multiple-choice question. I don't know where it's from or if there's any preceding context or something. If it's part of some sort of onramp or TMW tutorial, I'm blind to that. I can't use any of that. I can barely even keep my connection alive long enough to edit my own answer.

[Mahe Jabeen]

@DGM thanks! I give up on this question. I have tried many combination of answers and apparently, none of them are coorect!

[dpb]

I dunno about the quiz answers and forgetting about the nuances of imshow() raised; the Q? seems "straightforward-enough" for me -- it's asking which operations overflow the allowble range for the final data type of the operation and is dependent upon knowing how MATLAB casts the arithmetic operation to which operand type -- in other words, the ones which will be "white" are those which will saturate for the results that are returned as uint8 or >=1 for doubles--that's all it's asking for.

Based on that, the failures/"white" answers would be 2), 4), 5), 6) -- only 1) and 3) don't.

Empirically, you can check it out --

>> p=uint8(20); q=uint8(210);       % the constants
>> im2double(p+50)                  % (p+50) is uint8; convert to double, <1 so OK
ans =
    0.2745
>> im2double(p)+50                  % (p) to double first; then adds 50 -- >1 BAD
ans =
   50.0784
>> p+50                             % casts the '50' to uint8 so <255 --> OK
ans =
  uint8
   70
>> q+50                             % still uint8 but overflows --> BAD
ans =
  uint8
   255
>> im2double(q+50)                  % just casts the overflow to double  --> BAD
ans =
     1
>> im2double(q)+50                  % same issue as 2nd case --> BAD
ans =
   50.8235
>> 

Don't overthink the problem...

[Mahe Jabeen]

@dpb Thanks. Your explanation helped. I realized I was overthinking with "imshow" part.

[dpb]

The Q? doesn't refer to imshow at all; that was a red herring others threw into the mix.

Casting rules in MATLAB are unique and context-sensitive -- NB on the second that while it was written as the conversion to double first, reversing the order still returns the same value -- because the default numeric type is double and so the input interpreter does the conversion of the text '50' to double transparently. In Fortran, for constrast, the constant on the RHS of an assignment would be the default integer type; the stored type into a variable would depend on either the implicit or explicit typing rule in place for the given variable. A mixed precision operation without an explicit cast is implicitly promoted to default real (although surprises can await since an expression of integer values such as 1/3 will be computed as the result of integer division and be zero, the operands are NOT converted to float prior to the division).

MATLAB casts to the highest precision amongst the operands as a general rule although I don't know that that catches all permutations nor do I know where (or if) the rules are defined/documented completely. It's a "feature" I've noted about the MATLAB doc in general that being almost completely descriptional/functional it does not ever define the grammer fully as in, say, the Fortran or C Standard. Just as user manuals for those languages discuss "how", the compiler writer must instead refer to the Standard document for the implemetation of the compiler on precisely how any given syntax is to be interpreted. While I'm sure there's something similar inside TMW for MATLAB, being as it is a proprietary commercial product, that document is not available publicly; hence there are areas in the bowels the user simply does not and cannot know precisely.

Also this Q? is dependent upon the behavior of im2double that interprets the argument type and scales any int to the ratio of the value to the upper limit of the type -- it doesn't just do a cast() of the promotion of the value to double.

>> im2double(p)
ans =
    0.0784
>> double(p)
ans =
    20
>> 

you note are two totally different things...

>> double(p)/255==im2double(p)
ans =
  logical
   1
>>