"MagickModule - Swiss army knife of image process"

BlitzMax Forums/Brucey's Modules/"MagickModule - Swiss army knife of image process"

Russell(Posted 2009) [#1]
Where can I get this from? Saw this on your Google Code page but could find no mention of it anywhere else, nor a link to download.

What I'm looking for is a library that does some pretty basic things like draw an anti-aliased image on top of another image, blur effects, and so on.

Any information would be greatly appreciated!

Russell


xlsior(Posted 2009) [#2]
You'll need an SVN tool to download most of Brucey's modules.

I use slikSVN (free): after install, a batch file can download & sync up any changes:


c:\code\SlikSvn\bin\svn.exe checkout http://maxmods.googlecode.com/svn/trunk/ c:\code\blitzmax\mod\bah.mod




Russell(Posted 2009) [#3]
Thanks, xlsior! Too bad an SVN client isn't built in to BMax itself (replacing the very useful, but no longer there 'Syncmods').

Oh well, nothing like doing command-line MSDOS gymnastics in these days of point-and-click, drag-and-drop GUI interfaces, eh? ;)

Russell


Brucey(Posted 2009) [#4]
TortoiseSVN is quite a nice explorer-integrated SVN client. No command-line required :-)


xlsior(Posted 2009) [#5]
TortoiseSVN is quite a nice explorer-integrated SVN client. No command-line required :-)


I have tortoiseSVN installed as well, but SlikSVN allows me to check a whole bunch of SVN repositories all in a row just by double-clicking a batchfile.


Brucey(Posted 2009) [#6]
I actually prefer subclipse for all my SVN related activities :-p


Russell(Posted 2009) [#7]
Does anyone know why so many of these SVN clients are so huge? Just curious, as it doesn't seem like the task at hand warrants so much code (bloat?).

I'll check out both and see which one better suits me... ;)

Russell


theHand(Posted 2009) [#8]
Just for curious people and newcomers, Brucey wrapped GraphicsMagick, and not ImageMagick.
I wondered.


ImaginaryHuman(Posted 2014) [#9]
Is it okay to use the GraphicsMagic module and also FreeImage in the same app, and sell that app to customers?


Brucey(Posted 2014) [#10]
GraphicsMagick uses an MIT-style license.
FreeImage uses GPL (2 or 3), or FIPL which is fine for commercial applications. (You choose the license you want).

Not sure if you can use them both together. I'd have to do some tests first. They each use their own libjpeg and libtiff libraries.
I suppose it would be (more) useful if one could use the libraries from the other - then it wouldn't matter too much...


ImaginaryHuman(Posted 2014) [#11]
I was able to rebuild GraphicsMagick ok on Windows, once I also installed libxml. Then I copied the bah.mod/ folder to Blitz on my iMac and it got stuck here:

Compiling:Blob.cpp
error: invalid argument '-std=c99' not allowed with 'C++/ObjC++'
Build Error: failed to compile /Applications/BlitzMax1.49/mod/bah.mod/magick.mod/src/Magick++/Blob.cpp

Any ideas what might cause this? I'm on Mavericks and I believe I have the latest Xcode.


ImaginaryHuman(Posted 2014) [#12]
If I temporarily remove the blob.cpp file i get the same error on another cpp file

error: invalid argument '-std=c99' not allowed with 'C++/ObjC++'
Build Error: failed to compile /Applications/BlitzMax1.49/mod/bah.mod/magick.mod/src/Magick++/TypeMetric.cpp

But there are cpp files in free image and other modules that are building fine... just graphics magic is a problem?


Brucey(Posted 2014) [#13]
If you change the following in magick.bmx from :
?Not win32
ModuleInfo "CC_OPTS: -std=c99"

to
?linux
ModuleInfo "CC_OPTS: -std=c99"

It should build fine.

It appears the latest clang/llvm is more picky what flags you give it than previous versions.


ImaginaryHuman(Posted 2014) [#14]
Hmm. I changed that.

When I try a simple program to just import bah.magick, on windows max 1.48, I get a tonne of errors along these lines, many many pages of it:

C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/pub.mod/libjpeg.mod/libjpeg.debug.win32.x86.a(jdmarker.c.debug.win32.x86.o):jdmarker.c:(.text+0x302c): multiple definition of `jinit_marker_reader'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(jdmarker.c.debug.win32.x86.o):jdmarker.c:(.text+0x3d41): first defined here
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0x713): undefined reference to `__gxx_personality_sj0'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0x73c): undefined reference to `_Unwind_SjLj_Register'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0xa2b): undefined reference to `_Unwind_SjLj_Resume'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0xb24): undefined reference to `_Unwind_SjLj_Resume'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0xb38): undefined reference to `_Unwind_SjLj_Unregister'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0xb5d): undefined reference to `__gxx_personality_sj0'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0xb83): undefined reference to `_Unwind_SjLj_Register'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0xd0b): undefined reference to `_Unwind_SjLj_Resume'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0xdbd): undefined reference to `_Unwind_SjLj_Resume'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/magick.mod/magick.debug.win32.x86.a(glue.cpp.debug.win32.x86.o):glue.cpp:(.text+0xdce): undefined reference to `_Unwind_SjLj_Unregister'


Freeimage also gives me a tonne of similar errors:

C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/freeimage.mod/freeimage.debug.win32.x86.a(Plugin.cpp.debug.win32.x86.o):Plugin.cpp:(.text+0x5ca): undefined reference to `__gxx_personality_sj0'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/freeimage.mod/freeimage.debug.win32.x86.a(Plugin.cpp.debug.win32.x86.o):Plugin.cpp:(.text+0x5f0): undefined reference to `_Unwind_SjLj_Register'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/freeimage.mod/freeimage.debug.win32.x86.a(Plugin.cpp.debug.win32.x86.o):Plugin.cpp:(.text+0x703): undefined reference to `_Unwind_SjLj_Resume'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/freeimage.mod/freeimage.debug.win32.x86.a(Plugin.cpp.debug.win32.x86.o):Plugin.cpp:(.text+0x724): undefined reference to `_Unwind_SjLj_Unregister'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/freeimage.mod/freeimage.debug.win32.x86.a(Plugin.cpp.debug.win32.x86.o):Plugin.cpp:(.text+0x740): undefined reference to `__gxx_personality_sj0'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/freeimage.mod/freeimage.debug.win32.x86.a(Plugin.cpp.debug.win32.x86.o):Plugin.cpp:(.text+0x766): undefined reference to `_Unwind_SjLj_Register'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/bah.mod/freeimage.mod/freeimage.debug.win32.x86.a(Plugin.cpp.debug.win32.x86.o):Plugin.cpp:(.text+0x879): undefined reference to `_Unwind_SjLj_Resume'



Brucey(Posted 2014) [#15]
What version of MinGW have you got installed? The one recommended for your version of BlitzMax?

Otherwise, you just can't install any old MinGW and *not* change the contents of the BlitzMax/bin and BlitzMax/lib directory.


Derron(Posted 2014) [#16]
Thought ImaginaryHuman was an old hand concerning BlitzMax.

According to your Error the MinGW used to compile the modules was DW2 based instead of SJLJ (they are methods of exception handling).

You need to have all modules compiled using the same MinGW (and in this case you need the SJLJ-version)


Just to sum up the needed actions:
Download:
http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.1006.0/tdm-gcc-4.7.1-2.exe/download
like listed there:
http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.1006.0/

Create a batch file according to:
http://www.blitzmax.com/Community/post.php?topic=101593&post=1207353

Install MinGW and run adjusted script.


Detailed explanation:
install a SJLJ-version of your MinGW, eg. the TDM one. Brucey used "4.7.1". This is important if you use "bah.mod/****" as you then have the biggest chances for it to work (brucey might have tested a "build process").

The links above just explain what to do. As Brucey already noted: you need to copy the minGW-lib-files to the BlitzMax-installation. This is what the script in the second link does (just adjust the version string in there to 4.7.1).


bye
Ron


ImaginaryHuman(Posted 2014) [#17]
Thanks for taking the time to try to document it, but these steps did not work. Not only is one of your links broken but also I had to go elsewhere and find tips/attempts at copying other library files and such and adding extra paths to get it to build anything. It still errors out the same kind of errors on bah.freeimage, bah.magick etc. I also rebooted after completely reinstalling your version of MinGw you linked to. No different.

@brucey ... "What version of MinGW have you got installed? The one recommended for your version of BlitzMax?"

Where does it say anything about what version is needed for a specific version of BlitzMax, except strewn through various installation problem threads? I'm on 4.7.1 it looks like now, following the above instructions. Blitz 1.48 on windows.


ImaginaryHuman(Posted 2014) [#18]
I'm getting a bit better results on OSX.. but still get this error when importing bah.magick:

duplicate symbol _jinit_marker_reader in:
    /Applications/BlitzMax1.49/mod/bah.mod/magick.mod/magick.release.mt.macos.x86.a(jdmarker.c.release.mt.macos.x86.o)
    /Applications/BlitzMax1.49/mod/pub.mod/libjpeg.mod/libjpeg.release.mt.macos.x86.a(jdmarker.c.release.mt.macos.x86.o)
ld: 1 duplicate symbol for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Does the jpeg loader from brl have to be removed or something to avoid a clash?


ImaginaryHuman(Posted 2014) [#19]
Hm yes, bah.magick requires removal of the pub/libjpeg folder, and also the brl/jpegloader folder, otherwise it clashes. I was able to get it to import and compile finally on osx :)


ImaginaryHuman(Posted 2014) [#20]
Slight sticker.... bah.freeimage requires the removal of pub/libpng folder and brl/pngloader folder, which allows it to work, but then it can't be used in conjunction with bah.magick because bah.magick relies on brl's png code. Is there a possible workaround?


Derron(Posted 2014) [#21]
I updated the post with the correct link:
http://www.blitzmax.com/Community/post.php?topic=101593&post=1207353

Don't forget to rebuild ALL modules (else you run into conflicts).

@libjpg/libpng

I thought brucey stated somewhere that both mods use different libs and this makes it troublesome to use both simultaneously. You might need to adapt one mod to use the lib of the other one and voila...


bye
Ron


ImaginaryHuman(Posted 2014) [#22]
I did a fresh install and followed your exact steps and also identified the module conflict between libjpeg/jpegloader and bah.magick .... also bah.freeimage needs libpng/pngloader modules removed (but magick needs them), hence not using them together. Also I rebuilt everything. With those issues resolved things work fine... the only issue I have left is importing otus.lzma does not work. It seems something changed in a recent blitzmax or something to make it no longer be compilable.

C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/otus.mod/lzma.mod/lzma.release.win32.x86.a(LzmaEnc.c.release.win32.x86.o):LzmaEnc.c:(.text+0x47): undefined reference to `LzmaEncProps_Init'
C:/Users/admin/Documents/Docs/Other/BlitzMax1.48/mod/otus.mod/lzma.mod/lzma.release.win32.x86.a(LzmaEnc.c.release.win32.x86.o):LzmaEnc.c:(.text+0x175): undefined reference to `LzmaEncode'



Derron(Posted 2014) [#23]
You had the same problem already a year ago:

http://www.blitzbasic.com/codearcs/codearcs.php?code=2377


Just downloaded the current SVN revision of otus.mod.

Compiled with BlitzMax+MinGW4.6.2: debug and release (+threaded) work.
Compiled with BlitzMax+MinGW4.7.1: debug and release (+threaded) work.

Both was done using XP, trying Win7 now.

Edit: Windows7 compiled and linked flawlessly all combinations.

Did you really recompile the modules?
BlitzMax\bin\bmk makemods -a otus
BlitzMax\bin\bmk makemods -a -h otus

this would recompile threaded and non-threaded prebuilds of that module

What happens if you run "gcc -v" ?




the last line (gcc version 4.7.1...) is of importance - but I think you installed that correctly.

Albeit you said "exact steps" - just check if the files within BlitzMax\lib\... are having the same dates/sizes like the one in the MinGW-Dir (just compare some files). Maybe something went wrong.

@my Windows7 build:
It is a vanilla Windows7 with fresh installed BlitzMax+MinGW4.7.1.


bye
Ron


ImaginaryHuman(Posted 2014) [#24]
I downloaded otus.lzma 1.02 from here http://www.antepedia.com/detail/p/182782.html

rebuild full. same errors.

When I tried to look at the svn http://otus-mod.googlecode.com/svn/ with tortoisesvn repo browser, there are 4 empty folders and no files.

gcc -v gives:


I rebuilt otus from the dos window as instructed, same result.


ImaginaryHuman(Posted 2014) [#25]
If you have a fully compiling working copy on blitzmax1.48 with mingw4.7.1 could you possibly post it here or something so I can try it?


Derron(Posted 2014) [#26]
To download from SVN go to:

https://code.google.com/p/otus-mod/source/browse/
and click on "Download zip" (next to "source path").

But I will send you an email with my precompiled mod folder (only the lzma part) in 1 minute.
Without recompiling the modules it should work for you - and after recompilation too.


bye
Ron


ImaginaryHuman(Posted 2014) [#27]
Did that zip download, removed all but the lzma and lzma stream modules, rebuilt, still the same errors. Got your email thanks, trying that now.

Got your email, inserted the module and it compiled fine when imported, release and debug and threaded and single.... GOOD! Thanks... But I'm now trying to rebuild modules and having a bit of struggle... will update in a mo.


Derron(Posted 2014) [#28]
If you use something different to test instead of the "test.bmx" included in the otus.mod/lzma.mod-folder, please state it.

As you did the zip download (which I did), I doubt that my mail attachment will help.

You then use the same
- MinGW version
- Blitzmax version
- module-source

The only difference might be the ld.exe/ar.exe + lib files which might not be correctly copied to BlitzMax. But as the "sjlj"-errors are gone I assume that at least the lib-folder was copied correctly.

edit: ar.exe and ld.exe should be dated 2011/04/16.
My BMK used for this test was an unmodified one (none of Bruceys bmk_ng).

bye
Ron


ImaginaryHuman(Posted 2014) [#29]
To test I just did an empty untitled.bmx with the line `import otus.lzma`

Not sure on those exe dates, mine has a date modified of 11/30/2011 - that is, the copied ones from MINGW... the ORIGINAL ar and ld are dated as you said.


ImaginaryHuman(Posted 2014) [#30]
When I use the zip you emailed, programs compile file. When I try to rebuild modules after removing the .a and .i files from all subfolders and .bmx folders of otus module folder, I return to the same errors as before.

Regarding copying libraries, I copied all contents of the mingw/lib into blitz's bin/lib and also copied all of the mingw/gcc into blitz's bin/lib... overwrote whatever files, plus copied those two .exe's.


Derron(Posted 2014) [#31]
That is odd.

So after that copy-orgy you recompiled ALL modules?

bmk makemods -a
and
bmk makemods -a -h

?

Instead of copying ALL files, you just need to overwrite the lib-files already in the blitzmax folder (exception is ldsound which is missing on vanilla installs).


bye
Ron


ImaginaryHuman(Posted 2014) [#32]
Reinstalled bmax again (but kept mingw) .. hand-copied all lib files, only the ones that existed... found and copied them except for libunicows.a which does not exist in the mingw folders. I did not find any trace of `ldsound` either.

Re-copied otus.lzma to modules folder and removed all .a .i and .bmx files.

Rebuilding ALL modules with multithreading right now..


ImaginaryHuman(Posted 2014) [#33]
AHA! ... seems that copying too many lib files was the problem. Rebuilt all modules including otus and it is now working, yay!

Thanks for all your help on this.

This really needs a write-up of the exact steps for success.


Derron(Posted 2014) [#34]
libdsound.a
-> C:\Tools\MinGW32\lib\libdsound.a
(that file is needed if you work with rtaudio - so maybe other audio modules need it too, by default this file is NOT in the BlitzMax\lib-folder)

unicows is not in the mingw-folders, correct.


EDIT: That is why this script just copies files already existing in the Blitzmax\lib-folder while an easier copy-script would just copy all files existing in the mingw\lib-folder.

All in all I wonder why this should change the output of your compilation process - they are unused files in this situation.

bye
Ron


ImaginaryHuman(Posted 2014) [#35]
found and copied the libdsound.a, thanks

No idea on the influence of other files. I had previously copied all libs plus all of the gcc folder. I did it manually. PRobably using that batch file would've been more reliable.. .but I didn't know how to make a batch file or run it etc and all this dos-prompt stuff is so 1990's, lol


ImaginaryHuman(Posted 2014) [#36]
Oh wait, I take it back. .lol

After a complete full module rebuild, otus.lzma is again not working. Maybe when I thought it was working I didn't do something right and got a false positive.

I get the exact same errors. Again when I revert to the version you emailed it works, but rebuilding doesn't.


ImaginaryHuman(Posted 2014) [#37]
Strangely it does compile in non-multithreaded, but when multithreaded it does not.


Derron(Posted 2014) [#38]
Does it compile "multithreaded" using my precompiled module files? (this works here as reported earlier).


@making a batch file:
copy the content of the codebox linked in that above post.
Open up "notepad" (notepad.exe).
Paste the content
Adjust version-string and paths
Save that file as "patchMyBlitzMax.bat"... on the desktop or wherever you find it.
Run that patchMyBlitzMax.bat file. It will print some "file not found" and some "copied xyz" lines. This is because some files are within the BlitzMax\lib but not in MinGW\lib (like the unicows thing).


bye
Ron


ImaginaryHuman(Posted 2014) [#39]
Yes yours compiles fine.

Yours, or any version, where I take out all the build files and rebuild all modules multithreaded, importing the module to a program and building it fails to compile with the same error.

What mainly baffles me is how it could build fine with non-threaded but the threaded version thinks there are bugs.


Derron(Posted 2014) [#40]
What OS are you compiling on?

I could archive you a "ripped BlitzMax"-patch - just a "copy over" folder containing bin\ld.exe, bin\ar.exe and lib\*.*

Would be about 12mb uncompressed.

Using this you could minify the chances of having failed at "copy over mingw files".


Another thing (and nice to have):
I have multiple folders:
BlitzMax_4.7.1
BlitzMax

same for MinGW
MinGW32_4.7.1
MinGW32

During Installation of MinGW it added my c:\Tools\MinGW into the windows-path (so "gcc" can be called from everywhere).

If I now would rename "MinGW32" to "MinGW32_bak" and then "MinGW32_4.7.1" to "MinGW32", BlitzMax would use the other MinGW (4.7.1 instead of my other 4.6.2 - which is needed for rtAudio projects).
Surely there are "Switcher"-Batchfiles available somewhere, but this is quick and dirty.


I just explained this - to make you aware of chances that things compile without troubly using another MinGW-version (but they then might fail with other modules).


bye
Ron


ImaginaryHuman(Posted 2014) [#41]
Windows 7 Pro 64-bit

Hmm. It's all complicated.. for now I think I will just have to settle for throwing in the towel. It shouldn't be this hard. There may be more updates to bmax in future and the too may have problems being installed... until BRL really comes up with a failsafe easy way to install I think it's not worth the effort.

Thanks for all your time and help and insight though.


Derron(Posted 2014) [#42]
Hmmm I tested it with windows 7 "30 days demo" on a fresh installed virtual machine, should be 32bit.

Think 64Bit-Windows should not be the faulty reason of aborting a compilation.

Have a test with my attachment (new email) if you want.

I doubt it but maybe we have luck :D


bye
Ron


ImaginaryHuman(Posted 2014) [#43]
I think your patch + otus rebuild possibly worked. I will have to test it tomorrow. Thanks!


ImaginaryHuman(Posted 2014) [#44]
Hmm. Well, surprised, but for whatever reason, your patch worked. I can now build and rebuild to my hearts content in any mode and it all works properly. Thank you!

Honestly couldn't possibly explain to another person what they'd need to do to get BMax working if they were a newcomer with these issues... so strange. No idea why your files were any different from the freshly installed files.


Derron(Posted 2014) [#45]
Just take my patch file ... extract it to somewhere... and then compare the included files to yours (vanilla install + mingw install + executed batchfile|manual copy).

I am quite sure that you just missed to copy some files.


bye
Ron


ImaginaryHuman(Posted 2014) [#46]
Thanks again