I keep getting an error that the rows and columns must be of power 2. Am confused

cd 'C:\Users\hp\Desktop\research\New folder'

Error using cd
Unable to change current folder to '/users/mss.system.0s9itA/C:\Users\hp\Desktop\research\New folder' (Name is nonexistent or not a folder).

clc;
clear;
file_name=uigetfile({'*bmp;*.jpg;*.png;*.tif;';'*.*'},'select an Image File');

fileinfo = dir(file_name);
SIZE = fileinfo.bytes;
size = SIZE/1024;
disp('input image bytes');
disp(size);
X = imread(file_name);

[cratio,bpp] = wcompress('c',X,'wpeppers.wtc','spiht','maxloop',16);

disp('compression ratio');
disp(cratio);

disp('bits per pixels');
disp(bpp);

Xc = wcompress('u','wpeppers.wtc');
imwrite(Xc,'comperssed.jpg');

file_name='comperssed.jpg';
fileinfo = dir(file_name);
SIZE = fileinfo.bytes;
cSize = SIZE/1024;
disp('compressed image bytes');
disp(cSize);
delete('wpeppers.wtc');
subplot(1,2,1);
image(X);
title('Original image');
axis square;
subplot(1,2,2);
image(Xc);
title('Compressed image');
axis square;

D = abs(double(X)-double(Xc)).^2;
mse  = sum(D(:))/numel(X);
disp('mean square error is');
disp(mse);
psnr = 10*log10(255*255/mse)
disp('peak signal to noise  ratio is');
disp(psnr);

[Jan]

Please post a copy of the complete error message. Then the readers do not have to guess, in which line the error occurs.

[Ahereza]

Error using wcompress (line 289)
The number of rows and columns of image must be a power of two.

Error in tu (line 13)
[cratio,bpp] = wcompress('c',X,'wpeppers.wtc','spiht','maxloop',12);

Answer 1

[Jan]

Most likely this is the failing command:

[cratio,bpp] = wcompress('c',X,'wpeppers.wtc','spiht','maxloop',16);

If so, please read the documentation of the failing command:

https://www.mathworks.com/help/wavelet/ref/wcompress.html#mw_41f5e132-4177-4acd-a43b-7d0a536019f6

Input image to compress, specified as a 2-D array containing an indexed image or a 3-D array of uint8 containing a truecolor image. Both the row and column size of the image must be powers of two.

This means, that the dimensions of the image must be powers of two. This should not be confusing, but it is required for a wavelet transformation.

[EDITED]

Explicitly:

size = SIZE/1024;  % Do not redefine "size"

size is an important Matlab function. After defining a variable with the same name, it is hard to use. Therefore this "shadowing" should be avoided. Use e.g. "FileSize" instead.

If the image size is not a power of 2, resize the image:

X = imread(file_name);
imgSize  = size(X);
imgSize2 = 2.^nextpow2(imgSize(1:2));
if ~isequal(imgSize, imgSize2)  % Are dimensions a power of 2?
    X = imresize(X, imgSize2, 'lanczos3');
end

I do not know, if resizing using Lanczos3 is valid for your medical images. In my field of science any lossy ompression or resizing of images is avoided strictly.

[Ahereza]

so is wcompress able to compress some medical images because it is basically what am working on and whenever i use other images it works but for them it provides this error

[Walter Roberson]

Yes, wcompress is able to compress some medical images: the ones in which the rows and columns happen to be powers of 2.

[Ahereza]

Now the there are two things, how to know whether the image has rows and columns of power 2 and where one can obtain such images. I think that's my biggest challenge. Any help please.

[Walter Roberson]

The usual way to check the number of rows and columns would be to use the size() function, but that is not a possibility for you as you have replaced the size function with a variable named size.

Answer 2

[Walter Roberson]

file_name=uigetfile({'*bmp;*.jpg;*.png;*.tif;';'*.*'},'select an Image File');

You are taking an input image file, preferably bmp or jpg or png or tif, but any recognized image format is accepted.

SIZE = fileinfo.bytes;

You are examining the size of the image file -- how much space on disk was required to represent the image together with any header information such as date and time, or copyright notice, or whatever details about the image were stored (shutter speed, lens opening, sonar estimated distance to target, whatever happens to be present). This is an upper bound on how much disk space would be required to represent just the image itself using whatever compression scheme is in effect in the file

For example, suppose the compression scheme takes advantage of "run-length encoding", where each adjacent group of pixels with the same value are replaced by a repeat count and a single copy of the value, then if you were to sort the image then the result would have better run-length compression than a randomized version of the image; by examining the disk space you are not measuring how much "information" is in the file, you are measuring how good the compression algorithm for that type of file is at compressing images similar to the one you are dealing with.

[cratio,bpp] = wcompress('c',X,'wpeppers.wtc','spiht','maxloop',16);

You do wavelet compression of the image data stored in X, with the coefficients written to wpeppers.wtc

Xc = wcompress('u','wpeppers.wtc');

You uncompress the wavelet compression and put the result into Xc. Xc is going to be an array the same size as X is.

The ideal wavelet compression + uncompression cycle would give you back exactly the same data as was compressed. In cases where information is lost in the cycle, it is lost at places that make sense from a wavelet standpoint. Wavelets are composed of repeated cycles at different frequencies. and along the way some of the frequencies that have relatively small contribution might be assigned coefficients of 0, and some of the coefficients might suffer from round-off error on the calculations. The result of discarding small coefficients and of round-off is to affect several pixels during the reconstruction. The effect of the compression and decompression cycle is similar to doing a frequency-based filtering.

imwrite(Xc,'comperssed.jpg');

You write the result to a JPEG file. JPEG uses lossy compression by default, based upon a particular model of how humans perceive images. JPEG throws away information. JPEG blurs sharp lines. The image that gets stored in the .jpg file is not necessarily going to be the same as the data in Xc.

If your source image was JPEG, and only the minimum required information was stored in the file, and if you did not modify the image before imwrite() it out with the same JPEG compression settings, then the disk space required should be the same (the overall file might end up with a different stored date though.)

However.. you permitted reading from a number of different file types, and the file might have had additional information... and even if it was a JPEG file with no extra headers, then it did not necessarily have the same compression settings as what you are writing with.

With wavelets, because information from distant locations can influence local values during the compression / reconstructiion phase, even if you were working with a JPEG image with the same settings, the Xc array you get might turn out to be harder to compress than the image that was stored in the original file, so the file size of the rewritten JPEG image can turn out to be larger than the first file, even though you "compressed" the image according to the mathematical model of wavelets.

Looking at the file size of comperssed.jpg and comparing it to the original file size is thus of interest only if the point of the exercise is to demonstrate that compressing data up to three different ways does not necessarilly make sense to do. If the whole point of the exercise is not the negative result that the cycle involved can be worse than the original file, then chances are you are doing the wrong thing.

It would make more sense to compare the size of the original image file to the size of the 'wpeppers.wtc file .

[Walter Roberson]

I would like to further emphasize, that the result of a wavelet compression is not necessarily a file that is smaller than the original file, even when the compression works well. When wavelet compression is being discussed, the primary goal is to arrive at data structures that give a simplified wavelet representation, not necessarily to arrive at data structures that would take less space than the original if written to disk.

Imagine for example that you have a real-valued audio signal, and you start by taking the fft() of the signal. The fft() of the real-valued audio signal is the same size as the audio signal, but the entries are complex-valued, so by convention the fft() requires twice as much storage as the original real-valued signal. But it turns out that the second half of the fft() of a real-valued signal is always the (reversed) complex conjugate of the first half, so you could extract just the first half and later recreate the full fft by taking the complex conjugate of the extracted half. The information stored in the fft array is the same as the information stored for the real-valued audio signal.

Now take that fft() and find entries with low power, and zero them (making sure you do so in a symmetric way). The array does not change size when you do this. Depending how many entries you zero out, it might not be practical to find a more compact (less memory) representation of the array that omits the zeros. Or it might be possible to find a way that could store the result in less disk space, but that does not mean that using the compresed results for calculations would be efficient.

None-the-less, the fft coefficients array with some entries zeroed out, in some way represents a simpler signal, at least from the point of view of fourier representaiton. It would be a compressed signal in frequency domain terms . Not necessarily in time domain terms. Remember that a square wave or triangle wave is pretty simple in time domain, but in fourier frequency domain requires an infinite representation for exact reproduction, so zeroing some of the "low power" coefficients in the fft representation is going to lead to a more complex signal in the time domain, at least from a human viewpoint.

So wavelet compression is similar: you might come up with a "simpler" representation in wavelet space, that maybe could fit into less disk space than the original raw signal, but that does not mean that the reconstituted signal would take less disk space to represent or that the reconstituted signal would necessarily look simpler to humans.