Using gmic library

I want to use gmic library but have it not output the image but get the output image buffer. Is the only way to call gmic library is using run in gmic.h? How do I get the output as image buffer?

Please read this page first : http://gmic.eu/libgmic.shtml
Then, choose if you want to use the C++ or C API, and refer to this sample program then :

Thanks @David_Tschumperie . What is the file gmic_libc.h for ? It has all the right dllexport statements for windows but exports only 2 functions that are not used in the sample code that you gave the link for.

Basically I am having linking issues if i write similar code as in use_libgmic.cpp. I am using managed c++ in .net for which dllexport is necessary in the native code. And I realized that the dllexport is done only for 2 functions gmic::call and gmic::delete… . Why is that?

I’ve not used the C API yet. The .dll file is related to the C API only, not the C++ one.
Maybe @Tobias could help.

No, @Tobias cant help. But maybe @Tobias_Fleischer. :innocent:

Ha yes, sorry ! :slight_smile: @Tobias_Fleischer is actually the creator of the C API for the libgmic.

Is therr a libgmic for Windows which exports the functions that are used in the c++ example

if you compile it by yourself, then yes, you can create a library object with the C++ functions. But this will work only for linking with sources compiled with the same compiler, as the C++ API is not standardized yet.

Thanks. The float buffer used for image in use_libgmip.cpp:

 // Fill each image buffer with sinus values (with different frequencies). 
float *ptr = img; 
for (unsigned int c = 0; c<img._spectrum; ++c) 
   for (unsigned int y = 0; y<img._height; ++y) 
     for (unsigned int x = 0; x<img._width; ++x) 
       *(ptr++) = std::cos(x/(1. + i))*std::sin(y/(1. + i + c)); 
}

If I get image as base64 string, would representing it as array of floats and assigning it directly to float*ptr work too ?

To clear some things up:

The C++ API needs to be linked against the full G’MIC sources, so there are no DLL exports and you don’t need the gmic_libc.h for that.
If you look a the minimal usage example for that (https://github.com/dtschump/gmic-minimal/blob/master/src/use_libgmic.cpp) you will see that it uses the data structures defined by G’MIC and all its native data types and classes.

The C API uses a different approach: it is a generic library independent of G’MIC structures/classes/data types and can be accessed by many C and C++ compilers without needing access to the G’MIC sources.
If you look at the usage example (https://github.com/dtschump/gmic-minimal/blob/master/src/use_libcgmic.c), you will see that it only uses some very basic (G’MIC independent) structs in gmic_libc.h and only uses the two interface functions “gmic_call” and “gmic_delete_external”. You send it a pixel buffer in float or byte format and also get such a buffer for the processed output image in return.

Feel free to ask more questions about the usage of these interfaces. Not sure if I can answer all, but I’ll try. :slight_smile:

1 Like

Thanks. This is very helpful.

This question might not be particular to gmic but Did you try using the Windows dll for C API in visual studio? I am compiling with some code I have written and I continue getting linking errors which makes me wonder whether this is due to the dllls being compiled with mingw and having different mangled names than what visual studio would expect?

Since this a pure C API, you should not have any function/namespace export mangling problems.
In fact, I did cross-compilation tests in both directions: compiling the DLL in MinGW and accessing it from Visual Studio and the other way round, although for best performance, the DLL should be compiled in MinGW.
This is actually why I started this sub-project in the first place: I have several Visual Studio projects where I wanted to integrate G’MIC, but that was not really feasible doing directly because of some silly Microsoft bugs and restrictions and also because the MinGW builds were much faster. But compiling the C DLL in MinGW and then accessing it in Visual Studio worked perfectly in various versions, at least in my tests. What kind of problems did you run into?

I am using managed c++ in .net and then referrencig libcgmic as a native dll. Including the header file libcgmic in my source file, adding libcgmic.lib as an additional linker dependency in the project properties and adding the directory where libcgmic resides as additional library directories.

On compiling I get linker errors for both gmic_call and the gmic delete function. The error messages are "unresolved token __stdcall gmic_call …

Any idea what I can do ?

I haven’t tested with managed c++/.net, and I currently don’t have the time for it, unfortunately.

One idea: have you included the header gmic_libc.h like this:
extern “C”
{
#inlude “gmic_libc.h”
}

The “extern C” is needed to let the compiler know it is a C source/header file.

See also here: http://stackoverflow.com/questions/23701824/how-to-call-c-dll-functions-c-cli

Didn’t work. Let me try a few things and get back.

As a comparison, if I open a native c project in visual studio and link libcgmic.lib, it should work right?

Hi @Tobias_Fleischer,
How can I build the library on windows myself.can you tell me the command line arguments on mingw that you used to build

Using the provided Makefile ? $ make libc should work with MinGW.

Thanks @David_Tschumperle and @Tobias_Fleischer . Using the supplied .def files fixed the compilation problem for me. Haven’t run the built dll yet to know whether thus would get to correct linking on runtime.

I had two questions - one for david and one for tobias:
David : In https://github.com/dtschump/gmic-minimal/blob/master/src/use_libcgmic.c would using E_FORMAT_BYTE and then giving a byte array work ?

Tobias: Is there a way to avoid giving width, height and depth as input to the gmic library but instead calling a gmic function for that ?

Probably, but @Tobias_Fleischer should confirm this :slight_smile: