How to Stabilise export_fig output studied by size(I)?

[sami10007]

Code snapshot where assert is not passed because size(I) fluctuates; please see the line of export_fig where its parameters may cause the fluctuation; you can use any data in time, potential and C as test data; the observation is that with the same test data, you get those fluctuations in size(I) which should not be possible

hFig=figure('Units', 'inches', 'Position', [0 0 15 15]);
hax=axes(hFig);
imagesc(hax, time, potential, C);
xlim(hax, [1 2]); 
ylim(hax, [0 180]); 
axis(hax, [1 2 0 180]);

[I, alpha] = export_fig(filename, '-tif', '-q101', '-a1', '-m1', '-RGB', \ 
    ... '-nofontswap', '-nocrop', '-transparent', hax);
assert(unique(size(I)== [960 960*index]), \ 
     .... 'dimensions %d x % d not corresponding to resolution', size(I)); 
         %Fluctuations in size(I)
         % 928 968
         % 928 960
         % 960 960 - correct
         % 928 952

I have already verified the data in hax, and tried to set all possible limits which may cause the fluctuations in size(I). I think it may be because of some parameters of export_fig.

OS: Debian 8.5 64 bit
Linux kernel: 4.6 of backports
Export-fig: 25-sep 2016 version
Hardware: Asus Zenbook UX303UA
Matlab: 2016a

[sami10007]

Condition: vertical native resolution fluctuates with q100/q101 by 1 unit downward from the theoretical value but is the best differential condition.

I found out that the option -native prevents effectively those fluctuations

[I, alpha] = export_fig(filename, '-tif', '-native', '-q101', '-a1', '-m1', '-RGB', '-nofontswap', '-nocrop',  '-transparent', hax);

I am still doing long-term tests about it but short-term tests are all positive in effectiveness.

I found out that there is fluctuations about 1/10 times with -native resolution too. So significatly less than without -native but still too much. However, this time the result of the fluctuation seems to be constant only to one value, so maybe, there is some single factor causing it

% Fluctuations with `-native` q101
% 889   920

Let's study the effect of the parameter -q. I found these early results

%Fluctuations in I with native q101
% 889   920
%Fluctuations in I with native q99
% 889   912
%Fluctuations in I with native q100
% 889   920

It seems that native q100 is about the same as native q101, maybe slightly little less fluctuations.

[altmany]

Sorry, I cannot reproduce the problem. It works ok (consistently) on my Windows system.

I can tell you that -q101 produces a different EPS file (and therefore PDF) than -q100 or -q99. But I do not see how this would affect the image size(), it should only affect the compression.

[sami10007]

Can you please explain how -q101 differs from -q100. I want to get best possible quality and also usable when you are doubling the width resolution in a loop.

There is now a phenomenon in the results that if you double I width

• I width becomes 4x more
• I height becomes 2x more which both are wrong.

Expected output if you double I width

• native width resolution doubles

It would be nice to know you formulate I because input hax does not have such increased dimensions.

[altmany]

The ability in the latest version of export_fig (v3.35) to specify the output image size (see issue #315) should resolve the problem of assert failing due to inconsistent image size.

However, the underlying question of why the image size fluctuates remains unresolved, and the root cause is still unknown.