There are potential problems with the technique used to eliminate duplicates as consideration has not been given that the duplicate time values might be associated with different values of "x".
Hence comparisons of accuracy or timing between these m-files and alternative routines needs to be careful of different processing of duplicate input data points.
On another matter, it would also be advantageous to open the parameter MACC to the user to choose a value. As it stands, errors from the fast algorithm could be of order 2% (with limited testing) using the default MACC=4 [following Press et al.]. However, the discrepancy can be reduced by a factor of circa 100 (to an error of order 0.02%) by increasing MACC to 100; while this does reduce the speed of the "fast" algorithm, it remained quicker than the "slow" algorithm (in limited testing), and therefore also remained quicker than the two older routines from Shoelson and Savransky respectively.
For me, on an old PC (Intel Core2 Duo E8500 @ 3.16/3.17 GHz, 8 GB RAM, Win7 64bit) both of these algorithms are so far (with limited testing) significantly faster than the alternatives of Brett Shoelson (File ID: #993) and Dmitry Savransky (File ID: #20004).
FOR EXAMPLE, with a data set of 4403 data points (with no time duplicates):
Shoelson ~ 69 s
Shoelson (with processing for duplicates) ~ 84 s
Savransky ~ 93 s
Saragiotis (slow) ~ 10.5 s
Saragiotis (fast) ~ 0.2 s
Saragiotis (fast, with MACC=100) ~ 2.3 s
I had played around with the relevant commands to copy figures as high-resolution bitmaps, using the undocumented "hardcopy" function suggested by TMW staff
e.g. hardcopy(hF_StatsAVI, '-Dopengl', '-r100')
In comparison, your function is more convenient to use, and much better documented.
I am using it to save out PNG files with either whigte or transparent figure background. However, I was baffled when running the same commands which had been succesful previously began outputting images with black backgrounds, despite my setting
The problem seems to be that it is necessary to _manually_ select "Use figure color" in the "Copy Options" dialogue box, under "Edit" from the figure's menu bar.
I would normally want to produce a metafile with "Transparent background" when _copying_ the figure, except for some recalcitrant plots; hence, I don't usually have "Use figure color" selected.
I thought it might be possible to toggle this programatically, but the command
set(gcf, 'InvertHardCopy', 'off');
was not effective.
Anyway, these issues seem to point to flaws in MATLAB, rather than in your code.
By the way
is generates this message:
"Warning: Setting the ColorSpec to 'none' for a figure will not be allowed in a future release."
It still works at the moment, and personally I would rather it continued to work. I hope it is replaced by an alternative, and not just removed.
I also want to ask/comment about two specific problems:
(1) Reading a uint8 file
I open a LIF file which should have intensities 0 to 255, I guess (unless the bit depth is higher???). However, the results returned from this M-file are in the range of int8, that is from -128 to +127. Looking at the frequency histogram, this is clearly wrong. I can fix it like this:
% Begin DIV edit 2013-01-22 %
if sgn == 0,
whos sgn arr
arr = uint8(arr >= 0) .* uint8(arr) + uint8(arr < 0) .* (uint8(arr + 128) + 128);
% End DIV edit 2013-01-22 %
but I notice that the variable
sgn = loci.formats.FormatTools.isSigned(pixelType);
is already defined in the code, but never used for anything (see my previous post). Is there some bug there?
(2) Opening a LIF file
A Leica LIF file can contain multiple series. By default this code opens only the last series. I wonder if there is a way to access (in a controlled way) the other series in the file.