after compiling and installing imagick for php8 (and working through the problems that causes to occur), I can now convert svgs to images. However, after installing inkscape and checking the delegations for imagick, imagick is not detecting and using inkscape. without any further errors to work through, and after going through plenty of google pages, I am convinced I either missed something that should be installed or configured, or I plainly did something wrong. I would appreciate any directions and/or assistance.
below you'll find information regarding versions, code and configurations, if anything else is required, please ask and I'm happy to provide.
grepping SVG renderers using convert -list format | grep SVG gives me the 3 basic renderers (MSVG, SVG and SVGZ).
The php code used to render the final image is pretty basic and should not be related to the issue at hand, but here it is anyway:
class SvgRenderer
{
private static ?Crop $_crop = null;
private static Imagick $_im;
// ...
public static function stringToPng32($svg)
{
self::$_im = new Imagick();
self::$_im->setFont('../fonts/arial.ttf');
self::$_im->readImageBlob($svg);
self::$_im->setImageFormat('png32');
if(self::$_crop !== null) self::_applyCrop();
return self::$_im->getImageBlob();
}
// ...
}
The versions of php, inkscape and imagick are:
PHP: 8.0.9
Inkscape: 0.92.2
Imagick: 7.1.0-0
svg delegate rules:
<delegate decode="svg" command=""#RSVGDecodeDelegate#" -o "%o" "%i""/>
<!-- Change export-filename to export-png for inkscape < 1.0 -->
<delegate decode="svg:decode" stealth="True" command=""#SVGDecodeDelegate#" "%s" --export-png="%s" --export-dpi="%s" --export-background="%s" --export-background-opacity="%s" > "%s" 2>&1"/>
The first image is rendered locally using imagick and inkscape, the second one is rendered on a server running the exact same code.
expected result:
current result:
After even more searching, I finally found what caused the issue...
Inkscape 0.92 is the latest build for centos (not counting snap or other sandbox builds), which doesn't work with ImageMagick 7.0+ downgrading to 6.9.33 fixed the issue.
Related
I am trying to customize the color of the LaTeX inline formula when using Sphinx documentation package, and html output.
The details:
I have a file called func.rst, which includes the following line:
Let :math:`x_{1}` be a binary variable.
which is rendered successfully into LaTeX in the documentation I created with Sphinx.
(I have 'sphinx.ext.imgmath' listed in extensions in conf.py)
My goal is to have x_{1} colored in red.
Things I tried:
Adding the color inside the formula:
Let :math:`\color{red}x_{1}` be a binary variable.
while also defining
latex_elements['preamble'] = '\usepackage{xcolor}'
in the conf.py file.
Trying to define all math output globally with:
latex_elements['preamble'] = r'''
\usepackage{xcolor}
\everymath{\color{red}}
\everydisplay{\color{red}}
'''
Needless to say, both (and many more less promising ideas) failed.
Copying over my answer on cross-posted question at tex.sx:
As you seem to be targeting html with math rendered as PNGs images (or SVGs), the current config value to configure isn't latex_elements, but imgmath_latex_preamble.
I tested since and it works.
For completeness sake, I am adding here the full solution. (THANKS jfbu!)
In conf.py I defined extensions = ['sphinx.ext.imgmath', <some_more_unrelated_stuff>]
Also in conf.py I defined
imgmath_latex_preamble=r'\usepackage{xcolor}'
(EDIT: in ooposed to what I previously wrote,there is no need to define in addition imgmath_latex="/usr/local/texlive/2017/bin/x86_64-darwin/latex" thanks jfbu again)
In the .rst file where I have the latex expression, I have
Let :math:`\color{red}x_{1}` be a binary variable.
In the terminal I run
make clean html
("make clean" is the sphinx's best friend)
And its working! wohoo!
I'm using ghc parameter -dump-splices to see the static file names generated by Yesod while debugging.
But I have found that sometimes it displays the static files name ( eg: css_bootstrap_css) but most of the times it doesn't show any of the static files.
Am I doing something wrong here?
I'm attaching the dump file here.
Doing this should solve the issue:
touch Settings/StaticFiles.hs
Or even a cabal configure and build seems to work.
I am using .Net 3.5/4.0 with code in C#.
I am trying to get a version number of an exe file on my C: drive.
For example path is: c:\Program\demo.exe. If the version number of demo.exe is 1.0.
How can i use this path to grab version number?.
You can use FileVersionInfo.FileVersion to fetch this from a path.
var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.FileVersion; // Will typically return "1.0.0.0" in your case
Updated and modernized 2018 (e.g. string interpolation of C#6):
The accepted answer is partly not correct (ProductVersion is not typically returning three-part version) and a bit misleading:
Here is a more complete answer. To get the main text not too lengthy I splitted it in a short(er) summary which may be "enough" for a lot of people. You are not obliged to read the detailed second part, so please no tl;dr :-)
Short summary:
There are different versions (assembly version, file version, product version) of each file, but normally you will have them all equal to not get "version hell" already on file level (it will come early enough).
The file version (which is visible in Explorer and used in setups/installations) is, what I would name the most important to bother.
To achieve this, simply comment out fileversion in AssemblyInfo.cs file as below. This assures that the three possible different versions of one file are the same!
[assembly: AssemblyVersion("1.1.2.")]
//[assembly: AssemblyFileVersion("1.1.2.")]
E.g. for Semantic versioning you want to get only 3 version parts out of possible 4 :
Having an automatic build counting for every Visual Studio build is useful. But this build counting is not always useful to tell your customers, internal or external. So for mentioning the file version to windows, in title dialogs, I would advice to show only three parts v1.2.3 (and of course with semantic versioning):
using System.Diagnostics;
...
var versInfo= FileVersionInfo.GetVersionInfo(pathToVersionedFile);
string fileVersionFull = versInfo.FileVersion; // No difference here for versinfo.ProductVersion if recommendation in AssemblyInfo.cs is followed
string fileVersionSemantic = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
string fileVersionFull2 = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}.{versInfo.FilePrivatePart}";
FileVersionFull2 is just showing how to handle all 4 parts, except the "V" it contains the same as FileVersionFull .
Details:
First is a cheat sheet about how to get and set the three versions:
File version: [assembly: AssemblyFileVersion(..)] => System.Diagnostics.FileVersionInfo.FileVersion
Product version: [assembly: AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion
Assembly version: [assembly: AssemblyVersion(..)] => System.Reflection.Assembly.Version
Especially the defaulting may be confusing. Recommended SO link to understand details: FileVersionInfo and AssemblyInfo
EntryAssembly vs. ExecutingAssembly
For fully considering every case for getting the version of the running app, search elsewhere for more details, e.g. here:
Which is better for getting assembly location , GetAssembly().Location or GetExecutingAssembly().Location
Especially, there can be confusion, if EntryAssembly or ExecutingAssembly should be used. They both have advantages and caveats.
If you have the following code not in the same assembly as the .exe, e.g. in a helper assembly, things get more complicated. Usually you would use EntryAssembly then, to get the version of the .exe.
But: For unit tests in Visual Studio to test routines in a parallel .exe project, GetEntryAssembly() doesn´t work (my env: NUnit, VS2017). But GetExecutingAssembly() doesn´t crash at least, only during unit test you get the assembly version of the test project. Fine enough for me.There may be situations which are not as simple.
If wanted, you can omit the declaration as static making it really possible to get versions of several different assemblies in one program.
public static class AppInfo
{
public static string FullAssemblyName { get; }
..
static AppInfo()
{
Assembly thisAssembly = null;
try
{
thisAssembly = Assembly.GetEntryAssembly();
}
finally
{
if (thisAssembly is null)
thisAssembly = Assembly.GetExecutingAssembly();
}
FullAssemblyName = thisAssembly.Location;
var versInfo = FileVersionInfo.GetVersionInfo(FullAssemblyName);
..
}
}
Product version vs. file version:
ProductVersion of a file is shown in Windows Explorer too. I would recommend to maximally differentiate ProductVersion and FileVersion in the most "customer-visible" file (mostly the main .exe of application). But it could be of course a choice to differentiate for every file of the "main" app and let them all have them all the "marketing" ProductVersion which is seen by customer.
But experience shows that it is neither necessary nor cheap to try to synchronize technical versions and marketing versions too much. Confusion doesn´t decrease really, costs increase. So the solution described in the first part here should do it mostly.
History: Assembly version vs. file version:
One reason for having different versions is also that one .NET assembly can originally consist of several files (modules)- theoretically. This is not used by Visual Studio and very seldom used elsewhere. This maybe one historical reason of giving the possibility to differentiate these two versions.
Technically the assembly version is relevant for .NET related versioning as GAC and Side-by-side versions, the file version is more relevant for classic setups, e.g. overwriting during updates or for shared files.
In the accepted answer a reference is made to "pathToExe".
This path can be retrieved and used as follows:
var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion
Hope this saves someone from doing some unnecessary extra steps.
Where Program is your class name:
Console.WriteLine("Version = " + typeof(Program).Assembly.GetName().Version.ToString()) ;
I'm not sure if this is what you are looking for, but:
http://www.daniweb.com/software-development/csharp/threads/276174/c-code-to-get-dll-version
It says,
// Get the file version info for the notepad.
FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.SystemDirectory + "\\notepad.exe");
// Print the file name and version number.
Console.WriteLine("File: " + myFileVersionInfo.FileDescription + '\n' + "Version number: " + myFileVersionInfo.FileVersion);
Use this, it works:
using System.Reflection;
string v = AssemblyName.GetAssemblyName("Path/filename.exe").Version.ToString();
This works good and returns the version provided in AssemblyVersion:
using System.Reflection;
infoFileVersionInfo versInfo = FileVersionInfo.GetVersionInfo("path.exe");
string version = $"v{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
Solution 1
Dim fileVer As FileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.CurrentDirectory + "\yourExe.exe")
yourLabel.Text = fileVer.FileVersion
Solution 2
Get File Version Number
yourLabel.Text = Application.ProductVersion
Both solutions will give 1.0.0.0
I'm porting an OpenCV 2.2 app from Unix (that works) onto Windows 7 64-bit and I receive the following exception when cv::imwrite is called
"OpenCV Error: Unspecified error (could not find a writer for the specified extension) in unknown function, file highgui\src\loadsave.cpp"
The original unix app works fine on my Mac and Linux boxes.
Does anyone know what library or compiler config I could be missing that makes this work on Windows?
UPDATE:
I did the following things to get OpenCV running:
Downloaded the binaries for v2.2 from the OpenCV site for windows. I'm using 2.2 because the original app uses it and I don't want to complicate my build at this stage.
I am trying to imwrite to a .png file. I looked at the OpenCV code and noticed the necessity for external libs for Encoders such as Pngs or jpegs, so I tried writing to .ppm, .bmp which seems not to require deps, but I get the identical error.
An example of my usage is cv::imwrite("out.png", cv_scaled); where cv_scaled is of type cv::Mat with format CV_32FC1
Please remember the identical code works fine in unix
The fact .bmp or .ppm doesn't work this raises more questions:
Why don't these very simple formats work?
Is there a way to see a list of installed Encoders programmatically?
Thanks again for your kind assistance in helping me debug this problem.
Your current installation of OpenCV doesn't support the file format you are trying to create on disk.
Check if the extension of the file is right. If it is, you'll have to recompile OpenCV and add support to this format and possibly install the libraries you are missing.
That's all that can be said without more information.
EDIT:
As I have also failed building an application that uses the C++ interface of OpenCV (v2.3 on VS2005) I ended up using the following workaround: convert the C++ types to the C types when necessary.
To convert from IplImage* to cv::Mat is pretty straight forward:
IplImage* ipl_img = cvLoadImage("test.jpg", CV_LOAD_IMAGE_UNCHANGED);
Mat mat_img(ipl_img);
imshow("window", mat_img);
The conversion cv::Mat to IplImage* is not so obvious, but it's also simple, and the trick is to use a IplImage instead of a IplImage*:
IplImage ipl_from_mat((IplImage)mat_img);
cvNamedWindow("window", CV_WINDOW_AUTOSIZE);
// and then pass the memory address of the variable when you need it as IplImage*
cvShowImage("window", &ipl_from_mat);
Try
cvSaveImage("test.jpg", &(IplImage(image)));
instead of
imwrite("test.jpg", image);
This is a known bug in the version you are using.
From the OpenCV 2.2 API:
The function imwrite saves the image to the specified file. The image format is chosen based on the filename extension, see imread for the list of extensions. Only 8-bit (or 16-bit in the case of PNG, JPEG 2000 and TIFF) single-channel or 3-channel (with ‘BGR’ channel order) images can be saved using this function. If the format, depth or channel order is different, use Mat::convertTo , and cvtColor to convert it before saving, or use the universal XML I/O functions to save the image to XML or YAML format.
You might have more luck converting your file to 8 or 16 bits before saving.
However, even with single channel 8 bit files I have had unknown extension errors trying to save jpg or png files but found that bmp works.
I'm trying to use the new OpenCV 2.0 API in MS Visual C++ 2008 and wrote this simple program:
cv::Mat img1 = cv::imread("image.jpg",1);
cv::namedWindow("My Window", CV_WINDOW_AUTOSIZE);
cv::imshow("My Window", img1);
Visual Studio returnes an unhandled exception and the Console returns:
OpenCV Error: bad flag (parameter or structure field)
(Unrecognized or unsupported array type) in unknown function,
file ..\..\..\..\ocv\opencv\src\cxcore\cxarray.cpp, line 2376
The image is not displayed. Furthermore the window "My Window" has a strange caption: "ÌÌÌÌMy Window", which is not dependent on the name.
The "old" C API using commands like cvLoadImage, cvNamedWindow or cvShowImage works without any problem for the same image file. I tried a lot of different stuff without success.
I appreciate any help here.
Konrad
As I just commented, imread isn't working for me either. A little googling shows other people having the same problem; I guess it's a bug in the library code. For now, here's a hacky workaround:
IplImage* img = cvLoadImage("lena.jpg");
cv::Mat lena(img);
cvReleaseImage(&img);
This way, you can at least use the C++ API for the rest of your stuff.
There's help for this issue.
The solution is, that the usual proposed opencv library files in the linker are not working properly. Instead try to use the debug library files by this:
In Visual C++:
go to Project->Properties (or Alt-F7)
Configuration Properties->Linker->Input->Additional Dependencies
replace the usual
" cv210.lib cxcore210.lib highgui210.lib" by
" cv210d.lib cxcore210d.lib highgui210d.lib" - which are the debugging libraries.
The OpenCv 2.0 API commands should work now.
I had the same problem described above which turns out to be caused by the settings of the linker.
I found the answer in another thread,
OpenCV 2.3 and Visual Studio 2010.
To repeat it here:
Properties of your project (right click on it)
C/C++
General
include directory add the < your directory >\OpenCV2.3\include\opencv2, < your directory >\OpenCV2.3\include\opencv and < your directory >\OpenCV2.3\include
Linker
General
List item
Input
Add all the libs like opencv_core230d.lib opencv_highgui230d.lib and so on...
Once I've done the above, I can run imshow and imread + all other cpp functions seamlessly! OP's problem has probably already been resolved, but hopefully this will be useful to other people who are led here looking for the same solution.
Are you sure you added the whole path starting from /home/.... I had the same problem as you but when I added the whole path, things work out pretty well. The whole path had to be added despite the fact the path exists in the include files.
imread in openCV unlike Matlab does not return an error when file/folder is not found - instead it returns a null matrix, which in turn is reflected as an error during imshow.
Also, imread does not look for image files in the included folders or the workspace. So, specify the entire path whenever possible.
Please take a note of this for future references.
Firstly, you'd better compile your own version OpenCV.
I had the same error with the build (I got from Sourceforge), and solved by compiling my own version in debug and release versions.
And make sure you change the original system env variable PATH to the new build folder build/bin, then you could build and run the imshow() in Debug mode.
I believe this might be related to unicode.
Try the macro _TEXT()
For example:
cv::Mat img1 = cv::imread(_TEXT("image.jpg"),1);
Unicode in Visual C++ 2