I have installed ImageMagick in my system (windows), and its commands are there in system PATH. Its working absolutely fine through Command line
I want to call the "convert" function of ImageMagick from Matlab using system command.
'C:\Users\Vivek' is the Path to image. I have to test working of ImageMagick through Matlab, as i need it in further processing (Making input suitable to Tesseract OCR)
cmd= ['convert ' 'C:\Users\Vivek\208.jpg ' 'C:\Users\Vivek\208.png']
system(cmd);
It says Invalid Parameter - C:\Users\Vivek\208.png, I tried some other ways. But, all the time the problem is with the second parameters.
Need Help
Thanks
Windows comes with its own convert program, and it looks like you're calling that one because it's first on the path in this context. It's described here on ImageMagick's site: http://www.imagemagick.org/Usage/windows/#convert_issue
I do not have ImageMagick installed, and I get the same error message when I try calling convert. That's consistent with your code getting the wrong convert program.
C:\Users\janke>convert C:\Users\Vivek\286.jpg C:\Users\Vivek\208.png
Invalid Parameter - C:\Users\Vivek\208.png
Specify the full path to ImageMagick's convert program and it should work for you.
The solution mentioned in the last post is the standard way to solve the issue, but the simplest way to do this is to just rename the ImageMagick's convert.exe file to something else, like convert1.exe, and use this filename in your scripts.
Related
I'm attempting to get Octave working in Jupyter and while I can execute basic math, I cannot get plots to work. Regardless of what type of graphics library I try to use, I get an error similar to this:
error: feval: function '__init_gnuplot__' not found
error: called from
graphics_toolkit at line 98 column 5
Here's the code that faileds:
register_graphics_toolkit('gnuplot');
available_graphics_toolkits()
graphics_toolkit("gnuplot");
I did some investigation and my best guess is that it looks like it's looking for a file called __init_gnuplot__.cc, based on the fact I found a file with a similar name but ends with '-tst'. However, that file doesn't exist and grepping the entire file structure under the octave directory doesn't find any instances of the function in the error.
Has Anaconda removed that functionality? Does anyone know where that '__init_gnuplot__' function is supposed to be located? Or, better yet, does anyone know how to resolve this?
I have several Windows sourced p-files internally coded with the '\' file separator that I want to run on Matlab under macOS.
I get errors caused by the '\' because macOS uses '/'.
eg The pfile tries to call a file named "model\xyz' which causes a warning:
"Name is nonexistent or not a directory: model\ "
1) Is there code that I might insert somewhere to recognise the 'model\' call from the pcode file and change it to 'model/' before it is used by MATLAB addpath?
2) Is there a generic fix I could apply to the addpath code?
3) Or better still is there a way to modify the Windows p-file without access to its source code so that it will run under macOS?
There are several things you can do (none of which are particularly easy; listed here in increasing order of how nasty I think they are):
Contact the author of the code and ask them to fix it.
Install an older MATLAB version (R2007b <= ver < R2015b, I think) which allowed debugging (stepping into) p-files within MATLAB, then, assuming that there is some line in the original source code that does
filepath = ['model' '\' 'xyz.m'];
step until you see filepath appear in the workspace (having the wrong path in it), then simply edit the value to the correct path, and hope for the best.
(Essentially the same idea as before, but on newer MATLAB versions, VERY DIFFICULT to pull off) Obtain an external debugger, attach to the MATLAB process, run the p-file and scan the memory for the contents of filepath. When you discover it, change the value to the correct path and detach/disable the debugger.
If this code relies on some external (and open source) function to get (or use) the path, you can modify its behavior to output the string you want. This requires some knowledge about the source code.
Find/make a tool for decoding p-files and fix the resulting source code yourself.
For completeness I describe how my problem was solved:
As suggested by Dev-iL I was eventually able to locate the author and he modified his code. This is the best solution but it took some time and is not always possible.
Based on: https://au.mathworks.com/matlabcentral/answers/117110-dealing-with-and-windows-vs-unix-for-path-definition I located a module (I've forgotten its name) within the Matlab package which handles file calls and intercepted all incoming file path names containing the '\' Windows separator, and replaced them with the always acceptable '/'. This quick and dirty fix worked until solution 1. was obtained.
Thanks to all who responded so quickly to this question.
I have a script in perl that generates a .m file based on a series of parameters and then runs an octave algorithm through ticks like:
`octave my_script`;
And then I capture the results in a separate file. The problem is that even having installed the image package succesfuly mat2gray function is not working.
If I open manually octave like a separate console to be used manually, and call my script it does work perfectly. The issue appears only when calling the octave.exe from Perl. It shows:
error: `mat2gray' undefined near line 21 column 6
Which looks like the typical error you get when you don't have the image package (and I do have it installed and I'm able to usethe function on octave console directly). I already tried to iclude a line on my script at the very top to rebuild the package everytime my script runs, like so:
pkg rebuild -auto image;
But that didn't fix it. Anyone has seen this kind of odd behavior?
I'm using Octave 3.2.4, since I need that version due to some compatibility issues with other pieces of software that we need. And some plotting capabilities when called from perl don't work all that well. Just in case you were wondering.
For future reference, I replied to the question here.
I have recently been working with Matlab. My question stems from my usage over a few months and is something that I can't seem to solve. I have an external SVM toolbox (OSU-SVM) that I would like to interface to with my project. I am able to get the entire system to work when I add the path of the toolbox manually (Right click -> Add to Path -> Selected Folders and Subfolders). What I would like to do is add the folder in a script. I've tried the "addpath" command but for some reason I can't get it to find the library relative to the m-file (script) that I run the command from. The following is an example of the code:
% Add OSU SVM system
addpath(genpath('./osu-svm/'));
The reason the I'd like to add the path using a relative folder to the M-file is that the code needs to run in a different environment that will not have the toolbox install. The code is also going to be executed in a different OS to the one I am developing on. That is, I am running a Windows Matlab to develop the code and need to run the finished system on a Linux machine. The process of running my files needs to be as painless as possible and shouldn't require much input from the user. That is why I'm specifically trying to avoid manual addition of the path.
On a side note a similar problem occurs when I wish to use "uigetfile" using a relative path. I believe there is something I am missing that will help me solve both of these simultaneously. Any help would be greatly appreciated.
Instead of './osu-svm/' alone use
fullfile('.','osu-svm')
The reason it does not work for you on windows is that you are using forward slash file separators. Full file will make a file string containing the correct file separator for each OS.
The genpath example in the matlab documentation also uses fullfile
http://www.mathworks.co.uk/help/techdoc/ref/genpath.html
Furthermore, the '.' is kinda unnecessary as it just means "relative to the current directory" and can be left out of the command. Perhaps you meant one directory up?
'..'
???
I have a fairly simple question that has me stymied. I am trying to run an executable built from a simple C program using MATLAB as a shell, i.e. using the following MATLAB code:
FileName = ['D:\Users\person\Desktop\MATLAB\GUI','\Program.exe &'];
dos(FileName);
The executable correctly begins running, but crashes giving the error:
Debug Assertion Failed!
Program: D:\Users\person\Desktop\MATLAB\GUI\Program.exe
File: f:\\dd\vctools\crt_bld\self_x86\crt\src\fscanf.c
Expression: (stream != NULL)
The programs opens a text file, reads the input, performs math functions, and writes outputs back to another text file. I assume that this error means there is a problem reading from the text file, BUT-- when I run the executable by itself (i.e. Windows Explorer doubleclick), it executes flawlessly, as I would expect.
So, it's only MATLAB pointing to the file location that is causing the crash. Any ideas? Thank you.
Sounds like relative paths are the culprit. The Matlab command is running from whatever directory you've specified within Matlab; cmd runs from root or something like that (don't know much about Dos). That's why it works when you specify absolute paths. Change your Matlab directory to DOS root, and see if it works as originally coded.
Edit: Note that it's the path to whatever file Program.exe is trying to read that's the problem, not the path to Program.exe itself.