unit 8 and im2double and white pixel

2 次查看（过去 30 天）
Mahe Jabeen
Mahe Jabeen 2022-7-27
编辑： dpb 2022-7-31
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.
  1 个评论
dpb
dpb 2022-7-27
编辑：dpb 2022-7-27
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

请先登录，再进行评论。

请先登录，再回答此问题。

回答（1 个）

DGM
DGM 2022-7-27
编辑：DGM 2022-7-28
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.
  6 个评论
显示 4更早的评论
Mahe Jabeen
Mahe Jabeen 2022-7-31
@dpb Thanks. Your explanation helped. I realized I was overthinking with "imshow" part.
dpb
dpb 2022-7-31
编辑：dpb 2022-7-31
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
>>

请先登录，再进行评论。

类别

在 Help Center 和 File Exchange 中查找有关 Images 的更多信息

标签

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by