MATLAB eps output converted using MiKTeX's epstopdf wrongly displayed in Acrobat Reader

Question

This question does not contain any direct reference to TeX; however, I came across the problem while working with pdflatex, specifically when including eps output into a pdf file. Also, I expect the most expertise regarding the eps and pdf file formats on this SE. So I hope this question is on-topic. I have researched a couple of other questions regarding conversion of MATLAB output; however, none of them seemed to deal with the specific problem that I face, or the amount of detail in the question was extremely limited.

My problem is: Some graphics elements are not displayed in Acrobat Reader. Text is shown fine, and whether elements are displayed or not depends on the export routine and it's size. It does not seem to be a cropping issue. I do not see that problem in other viewers. So I will try the solution from Certain EPS files don't convert with epstopdf, but ...

... my question is, why does that happen anyway? Is that a bug in Acrobat Reader? In epstopdf? In MATLAB? Or is that tool chain using a feature that I should better avoid because it's known to cause problems?

As I said, I have reduced the problem to one which is independent of pdflatex.

This is how I generate the files in MATLAB, I hope that code is understandable to anyone.

for dim = 32 : 33
    im = rand(dim);
    suf = sprintf('_%d.eps', dim);

    close all;imagesc(im);axis off;text(0, 0, 'Text');
    saveas(gcf, ['saveas' suf]);
    system(['epstopdf saveas' suf]);

    close all;imagesc(im);axis off;text(0, 0, 'Text');
    print(gcf, ['print-d' suf], '-deps');
    system(['epstopdf print-d' suf]);

    close all;imagesc(im);axis off;text(0, 0, 'Text');
    print(gcf, ['print' suf]);
    system(['epstopdf print' suf]);
end

The files

saveas_32.pdf and print-d_32.pdf are the files that are displayed wrong. This is what this looks like:

My observations

• All eps files look fine in GSview.
• All pdf files look fine in Google Chrome.
• saveas and print-d files look identical everywhere; this is not surprising; it is rather surprising that print files have an ugly border that I would need to crop manually; I would not like to do that.
• All other (non-print) pdf files look pretty perfect in terms of composition.
• All 33 pdf files look fine in Acrobat Reader.
• The print_32 pdf file looks fine in Acrobat Reader (but that ugly border...).
• All other (non-print), 32 pdf files are missing the image. The text is at in the expected position.
• In 32 eps files, the image data is stored as a "pattern".
• In 33 eps files, the image data is stored as a java.awt.image.BufferedImage.

Version information

GSView 5.0

GPL Ghostscript 9.20 (2016-09-26)

MATLAB Version: 9.1.0.441655 (R2016b)
Operating System: Microsoft Windows 10 Pro Version 10.0 (Build 14393)
Java Version: Java 1.7.0_60-b19 with Oracle Corporation Java HotSpot(TM) 
64-Bit Server VM mixed mode

MATLAB's Ghostscript:
It seems that MATLAB does not ship with Ghostscript any longer. 
From pdf files saved with MATLAB, I find this:
Apache FOP Version 2.2.0-SNAPSHOT: PDFDocumentGraphics2D
I cannot see if this is used to generate eps output, too.

C:\>which epstopdf
/Program Files/MiKTeX 2.9/miktex/bin/x64/epstopdf

C:\>epstopdf --version
MiKTeX EPS-to-PDF Converter 2.9.6200 (MiKTeX 2.9.6210 64-bit)

From EPS files, which are converted using this tool:
MiKTeX GPL Ghostscript 9.19

Adobe Acrobat Reader DC 2015.023.20056

Chrome Version 55.0.2883.87 m (64-bit)

Answer 1

The answer is simple, and @samcarter's comment made me find it. It was the display settings in my installation of Adobe Reader. I had "Replace Document Colors" turned on (I remember playing around with this settings once), and even though this does not change much in a regular document (and certainly doesn't remove images), it does remove my example 32x32 (or smaller) images. I guess the difference between 32x32 and 33x33 is that the latter are encoded as bitmaps (and not replaced), while the former are encoded as patterns of a shape (and replaced). This must be a distinction that the initial encoder (in this case, MATLAB) makes, as you see that difference in the eps files.

Turning off that option brings back my images!