Implementing JBIG in MATLAB

I am trying to implement JBIG, I want to know the compression ratio for certain images. The only open source implementation is done by Markus K. the JBIG-KIT however it is written in c.

https://www.cl.cam.ac.uk/~mgk25/jbigkit/

However there are a certain implementation of MATLAB that is using the executables of from it's pbmtools

https://in.mathworks.com/matlabcentral/fileexchange/5104-toolbox-wavelets/content/toolbox_wavelets/perform_jbig_coding.m

I was able to generate the pbmtojbg and jbgtopbm executable and put them in the same folder as the .m file. However the program is not picking them. In some older discussions they have stated the use of callib() function but I am not sure how that would be able to help here.

Please help.

[Walter Roberson]

Why not call the jbig-kit from MATLAB?

[sahil sharma]

By making it's MEX file?

[Walter Roberson]

If it has one. Otherwise loadlibrary()

[sahil sharma]

ok..

@Walter Roberson

Can you please tell me the questions regarding the following MATLAB code. It is code from wavelet toolbox with path and commands added for the JBIG-KIT's executables.

function [y,nbr_bits] = perform_jbig_coding(x)
% perform_jbig_coding - perform binary image coding
%  [y,nbr_bits] = perform_jbig_coding(x);
%  It requires pbmtojbg and jbgtopbm executable.
%  Copyright (c) 2006 Gabriel Peyr
name_pbm = 'b.pbm';
name_jbg = 'c.jbg';
if size(x,1)>1 && size(x,2)>1
    % forward transform
    % save as pbm
    imwrite(rescale(x), name_pbm, 'pbm');
    % convert to jgib
    !/Users/sahilsharma/Documents/MATLAB/JBIG/pbmtojbg -q b.pbm c.jbg
    % read jbig file
    fid = fopen(name_jbg);
    if fid<0
        error('Unable to open Jbig file.');
    end
    [y,cnt] = fread(fid, Inf);
    fclose(fid);
    nbr_bits = length(y)*8;
    % remove tmp files
    !del c.jbg
    !del b.pbm
else
    % backward transform
    fid = fopen(name_jbg, 'wb');
    if fid<0
        error('Unable to open Jbig file.');
    end
    fwrite(fid, x);
    fclose(fid);
    % convert to pbm
    !/Users/sahilsharma/Documents/MATLAB/JBIG/jbgtopbm c.jbg b.pbm
    % read pbm
    y = imread(name_pbm);
    % remove tmp files
    !del c.jbg
    !del b.pbm
    nbr_bits = -1;
end

I have added the path here to run my code. It is working now. However I have two doubts,

1) !del <file name> command is not working, MATLAB is telling that "Command not found:del". So I thought that "rm" might work here. However, that is also not working, if you have any idea how will I be able to delete those files, please do tell.

2)[y,cnt] = fread(fid, Inf); (I have also bold this command in code), am I getting encoded values here? Cause I need to find the compression ratio achieved by JBIG. JBIG uses context based arithmetic encoding. So I wanted to know if the [y,cnt] reads the encoded data. As through this I would directly be able to get CR as I know the original size.

[Walter Roberson]

Use delete to delete files.

You never do anything with the content of named_jpg except find length() of it. You should instead

dinfo = dir(name_jbg);
cnt = dinfo.bytes;

which will tell you the size on disk of the file.

I need to find the compression ratio achieved by JBIG

Looking at the file size will not tell you that, not exactly. Every image file has headers that describe the image (the amount of detail can be variable especially if EXIF is used.) Some of that information may be needed in order to reconstruct the image, such as the image height and width and number of color panes, and a code indicating which compression scheme was used. But the rest of it might just be overhead, nice to have but not necessary. For example there might be room for a copyright notice, or (common) there might be a description of the X and Y resolutions. The essential information such as height and width and encoding scheme needs to be considered to be part of the size of the compressed representation, but copyrights and resolutions and time the file was created and such should not be considered to be part of the size of the output representation -- they are elements of the "container" but not of the compressed representation. Disk size tells you the size of the container, but not the size of the "essential" parts of what is stored.

Sometimes what you need to do is compress an empty image, then an image with one grayscale pixel, then an image with one color pixel, and a couple of other possibilities -- for example how does the size of one row with 32 columns compare to the size of two rows with 16 columns? You can then build a proposed model and fit the known values to try to figure out what the various components are that go into determining the output size.

... Basically it is typically better to analyze the code to figure out how to calculate actual compression ratio as distinct from container overhead.