dec2base working differently on a matrix than on individual values

I'm trying to encrypt some images (as an example, not for real use), and part of the method uses DNA encryption. For this, I have to convert the uint8 matrix that the image greyscale values are stored in (for R, G, and B, I separate them beforehand) to binary.

The code I'm running is:

message_Image = imread ('baboon.tiff');             % reads in the image
message_Image_R = message_Image(:,:,1);             % Separates the red channel
message_Image_R_bin = dec2base(message_Image_R,2,8) % Converts values to binary

The value of message_Image_R(1,1) is 164 (a uint8)

The first value that message_Image_R_bin prints out in the command window upon execution is '01010100'. This, however, is 84 (164 in binary is '10100100')

When execute dec2base(164,2,8), it results in '10100100'. Thus the code works fine on the individual number, but not on the matrix.

What am I doing wrong here?

[Giuseppe Inghilterra]

Hi, I tried on my own and it seems that dec2base function works. Check again your result or could you please attach your .tiff file or .mat file with message_R matrix?

[Vincent Crasborn]

Thanks for your fast reply!

Annoyingly it won't let me upload the .tiff, however it is available at this link (called 4.2.03)

I have also attached the message_Image_R.mat.

For clarity, I also have a screenshot of the message_Image_R.mat below, along with the first couple of lines of the message_Image_R_bin. I would expect the values highlighted to correspond to eachother, however this does not seem to be the case.

Answer 1

[Guillaume]

From your screenshot, it looks like you've typed:

>> message_Image_R_bin

at the command window and scrolled back up until the window stopped scrolling. If you're using matlab default settings, the command window only retain the last 5,000 lines. Considering that your char array has 262,144 lines, you're nowhere near the 1st element.

>> message_Image_R_bin(1, :)  %look at 1st row
ans =
    '10100100'

dec2base works correctly once you look at the correct element.

Note: you could use dec2bin instead of dec2base, which saves you from specifying the base.

[Vincent Crasborn]

That's exactly what I did, thank you very much for spotting that! I'll be honest as well - I'm quite new to matlab so I tried to read out the first row and didn't manage, which is why I was trying to use the output in the terminal window.

I'll also use dec2bin carrying forward, I was using it originally but then went to dec2base during my troubleshooting and never changed it back.

Thanks again, all of the above is super useful!

Answer 2

[Steven Lord]

That's not the first element in M. That's the first element that the Command Window scroll buffer contains. Previous rows in the output of dec2bin scrolled out of the buffer.

If you were to display dec2bin(M) the display would contain 262,144 rows, one row per element in M. The first line would look like this (which I generated using a 10-by-10 random M in release R2019b.)

>> M = randi([intmin('uint8'), intmax('uint8')], 10, 10);
>> dec2bin(M)
ans =
  100×8 char array
    '10100101'

You don't have such a header on your display. The default Command Window scroll buffer length is 5000 if I recall correctly; you can see this by opening up the Preferences in the Environment section of the Home tab on the Toolstrip. The scroll buffer preference is in the Command Window section under MATLAB in the Preferences page.

If we generate a larger M, store the output of dec2bin into a variable and display the first few rows we should see that it corresponds to the first elements in M.

>> M = randi([intmin('uint8'), intmax('uint8')], 512, 512);
>> D = dec2bin(M);
>> M(1)
ans =
    96

>> D(1, :)    
ans =
    '01100000'

>> bin2dec(D(1, :))
ans =
    96

Looks correct to me. We can check the whole matrix by reversing the process.

>> isequal(M, reshape(bin2dec(D), size(M)))
ans =
  logical
   1

[Steven Lord]

As Guillaume correctly pointed out, you were using dec2base but the same explanation applies to dec2base as to dec2bin.

[Vincent Crasborn]

Thanks to you too for your fast response and detail, I really appreciate it!

I was doing exactly that, unaware of the limit to scroll lines (though in hindsight this makes sense, as it was getting rid of a load of other outputs I had beforehand).