This is a modification of previously submitted APPLYHATCH_PLUS.
APPLYHATCH_PLUSC creates a bitmap version of the defined figure where colored elements are replaced with specified colored hatch patterns.
APPLYHATCH_PLUSC allows for the definition of colors for the hatch patterns. Color may be defined using char string or RGB values. Various examples are provided showing some possibilities of APPLYHATCH_PLUSC and MAKEHATCH_PLUS.
Note: This function is different from Brandon Levey's APPLYHATCH_PLUSCOLOR, which has slightly different functionality and syntax.
I don't really understand this comment. If you mean that the resolution of the numbers (tick labels, etc.) is poor, this is due to the fact that this function creates a BMP image. If the resolution is not to your liking, you simply need to increase the DPI. This is what I do for published works, as opposed to screen resolution (the default). Inceasing the DPI will also affect the pattern density, so some playing may be necessary to get exactly what you want.
Thank you. But the number is ugly.
I have made some very small revisions and the function now works again.
I have tested all examples and there are no more problems as reported.
seems to be outdated, even the example results in a bad quality plot with Matlab R2015a
When using "aplyhatch_plusC" function, I found the following error.
PATTERN and PATTERNCOLORS must be the same length.
Would you please guide how to fix this error.
Thanks in advance.
I used both applyhatch_plus and makehatch_plus as directed in example given inside the applyhatch_plus. However, in both case I am getting an error stating as below:
im_hatch = applyhatch_plus(gcf,'\-x.',600);
"Attempted to access colorlist(1,2); index out
of bounds because numel(colorlist)=1.
Error in applyhatch_plus>nextnonbw (line 142)
colors = (colorlist(out,1) == bits(:,:,1))
Error in applyhatch_plus (line 69)
I am sure as people had used it multiple time, it is working.
But I am not sure what wrong I did.
Thank you for your help.
This correction has now been included in the recent update.
When you test the length, now on line 95, you use the length function which returns the number of elements in the longest dimension (eg. A = [2x3] then length(A) = 3) This will cause a patterncolor matrix with <3 colors (rows) to fail because length(patterns) <3 and length(patterncolor) = 3.
If you use size(patterncolors,1) instead of length(patterncolors) (in the condition on line 95) this problem will be removed as it only returns the number of elements in the first dimension.
I am sorry but I don't understand the proposed modification. It is necessary to have an equal number of entries in PATTERNS and PATTERNCOLORS, otherwise there would be too few/many combinations. The PATTERNCOLORS can be either a string array of color chars, or a 3 column RGB value. This cannot be more or less than 3 to be RGB.
If you have a specific example where there is a problem, please send it to me.
I had to make an alteration to line 97 of applyhatch_plusC to handle a matrix with less than 3 rows for patterncolors.
96: [patterncolors_row patterncolors_col] = size(patterncolors);
97: if length(patterns) ~= patterncolors_row
Do you think you could make this, or another appropriate alteration, to allow matrices with less than 3 rows.
applyhatch_plusC applies to the entire figure, subplots included, so I don't understand the question. You cannot, however, use different hatching rules for two subplots. But, if you assure that the original subplots do not have any colors in common, you should still be free to make the results be anything you want.
anyway to use it with subplots?
Helped me a lot!
Small edits to correct reported errors.
Correction to account for situations with less than 3 colors, as noted by commentors.
Now includes modified makehatch_plus to allow for variable thickness hatches