Phewww.. got another dropbox suspension (nothing left now) though I could just made another clones but...
Apologize for the goners, will try to back it up at googlecode someday.
29 August 2012
25 August 2012
Three swiss-army image tool
In the context of mainstream usage, ImageMagick probably held the swiss-army status for automated/mass image processing and we could argue why not GraphicsMagick instead? ImageMagick has the most complete raster image format support (including good read but mediocre write support for vector image) and the most important is they have detailed yet easy to follow tutorial and manual to let users know why it's a swiss-army tool.
The other two have different niche but capable of doing many of mainstream usage: VIPS and the fairly new OpenImageIO (used by Blender). The first was best know as the specialist for processing large image (large = very very high resolution) without choking your RAM, the latter is currently better known as a library, thanks to its permissive BSD license but I see the potential for its interface to replace ImageMagick because OIIO also a bit faster in conversion task. VIPS has extensive mathematical operation which make it also scientific niche, OIIO in other hand have distinguished texturing features which make it a bit 3D graphics niche, at the moment OIIO CLI tool was rather simplistic but I'm looking forward for big evolution in this area. Both has official python binding support which should be more interesting for advanced users than what their CLI tool offer additionally VIPS has GUI interface called nip2 which IMO may hinder its true ace.
Even so I found none of them have support for other specific task such as RAW image processing or decent vector image conversion which I resolve by using several utilities. In the end I guess there is no such of a real swiss army image tool yet... not at FFmpeg level at least or imaging was just too broad to cover entirely.
What I wish for these tool is a kind of loadable and user-friendly inline/offline FX subsystem ala GIMP-fu/PyGIMP where artists can share/reuse/enhance their template.
Binaries (mingw build):
OpenImageIO 1.0.8: oiiotool.exe (1.7 MB) maketx.exe (1.7MB) since I don't build iv here is a small exrdisplay.exe (300 KB)
VIPS 7.30: vips.exe (2.1 MB)
ImageMagick 6.7.8-6: convert.exe (2.1 MB)
Features enabled as much as possible with exception some ImageMagick's vector support which I found not that good. This builds can be considered as update for my previous ImageMagick build.
The other two have different niche but capable of doing many of mainstream usage: VIPS and the fairly new OpenImageIO (used by Blender). The first was best know as the specialist for processing large image (large = very very high resolution) without choking your RAM, the latter is currently better known as a library, thanks to its permissive BSD license but I see the potential for its interface to replace ImageMagick because OIIO also a bit faster in conversion task. VIPS has extensive mathematical operation which make it also scientific niche, OIIO in other hand have distinguished texturing features which make it a bit 3D graphics niche, at the moment OIIO CLI tool was rather simplistic but I'm looking forward for big evolution in this area. Both has official python binding support which should be more interesting for advanced users than what their CLI tool offer additionally VIPS has GUI interface called nip2 which IMO may hinder its true ace.
Even so I found none of them have support for other specific task such as RAW image processing or decent vector image conversion which I resolve by using several utilities. In the end I guess there is no such of a real swiss army image tool yet... not at FFmpeg level at least or imaging was just too broad to cover entirely.
What I wish for these tool is a kind of loadable and user-friendly inline/offline FX subsystem ala GIMP-fu/PyGIMP where artists can share/reuse/enhance their template.
Binaries (mingw build):
OpenImageIO 1.0.8: oiiotool.exe (1.7 MB) maketx.exe (1.7MB) since I don't build iv here is a small exrdisplay.exe (300 KB)
VIPS 7.30: vips.exe (2.1 MB)
ImageMagick 6.7.8-6: convert.exe (2.1 MB)
Features enabled as much as possible with exception some ImageMagick's vector support which I found not that good. This builds can be considered as update for my previous ImageMagick build.
Static library attempt for GTK
In my previous post when I had to make rsvg-view a static build, a complete set of static GTK libraries needed. GTK known to refuse being build as static library on Windows. Obviously there is lot good reason (be it Windows or not), GTK is a library with lots of addons (theoretically a GLib based one) so a modular/extensible approach chosen, then if I recall internationalization won't work unless in dll mode, then GTK is known using lot of settings files and modules scattered in etc-lib-share folder, then in version 3 there is DBus stuff which all of these make it almost a deal breaker for static build mode. Although some modules (found in pango, gdk-pixbuf, gtk) can be statically linked to main library, others are not (need modification) such as wimp theme engine.
For this minimalistic use case (rsvg-view) where basically a window with just 2 zoom buttons, a static build would be nice eh?
Oh well let's just get it on...
Firstly this is GTK-3 that I tried which should prompt a serious warning message about stability/maturity. Historically in version 2.x IMO there is only 3 stable, good or sane version for Windows: the last 2.12.x, 2.16.x and 2.24.x. I did try make static GTK-2 (2.24.10) however almost all but three tests mysteriously crashed during startup, here is one of that survived: testtreecolumns (unfortunately not LTO optimized so it's a bit too big)
The main thing that prevented static linking is multiple definition of dllmain. In case you're not aware, GLib starting with 2.30 support static build but broken in 2.32 since glib-init introduced but is trivial to fix. So based on how this static glib work we could also do the same to gdk-pixbuf, pango and lastly to gtk itself:
- override the Windows guard in configure script which prevent static build. hint: "DLL on Windows"
- make sure all possible and desired modules being "bundled" via configure
- initialize hmodule instances as null instead of uninitialized
- prevent dllmain from being compiled by adding #ifndef DLL_EXPORT
- assign declspec instances as nothing when #ifndef DLL_EXPORT (or create your own guard) instead of dllimport/dllexport (seems GTK-3 somehow omit this already)
note: DLL_EXPORT and PIC are common flags used by libtool during compilation, they are off when configured with: --enable-static --disable-shared
This way, path finding and internationalization still works as expected. Here is example of gtk3-demo in static binary: gtk3-demo.7z
It would great to bundling it in my MinGW distro... kinda rare to see C-based GUI library, not that C is good for GUI
For this minimalistic use case (rsvg-view) where basically a window with just 2 zoom buttons, a static build would be nice eh?
Oh well let's just get it on...
Firstly this is GTK-3 that I tried which should prompt a serious warning message about stability/maturity. Historically in version 2.x IMO there is only 3 stable, good or sane version for Windows: the last 2.12.x, 2.16.x and 2.24.x. I did try make static GTK-2 (2.24.10) however almost all but three tests mysteriously crashed during startup, here is one of that survived: testtreecolumns (unfortunately not LTO optimized so it's a bit too big)
The main thing that prevented static linking is multiple definition of dllmain. In case you're not aware, GLib starting with 2.30 support static build but broken in 2.32 since glib-init introduced but is trivial to fix. So based on how this static glib work we could also do the same to gdk-pixbuf, pango and lastly to gtk itself:
- override the Windows guard in configure script which prevent static build. hint: "DLL on Windows"
- make sure all possible and desired modules being "bundled" via configure
- initialize hmodule instances as null instead of uninitialized
- prevent dllmain from being compiled by adding #ifndef DLL_EXPORT
- assign declspec instances as nothing when #ifndef DLL_EXPORT (or create your own guard) instead of dllimport/dllexport (seems GTK-3 somehow omit this already)
note: DLL_EXPORT and PIC are common flags used by libtool during compilation, they are off when configured with: --enable-static --disable-shared
This way, path finding and internationalization still works as expected. Here is example of gtk3-demo in static binary: gtk3-demo.7z
It would great to bundling it in my MinGW distro... kinda rare to see C-based GUI library, not that C is good for GUI
SVG viewer for Windows
I'm looking for a simple svg viewer for which can be invoked from command line and found some candidates:
- SVG Viewer from QT 4.8.2's example (3 MB)
- SVG test from AGG 2.5's demo (178 KB)
- RSVG View from librsvg (2 MB, explicitly need file input, otherwise will silently quit)
It should be static(standalone) as usual, preferably small and must be fast. Both from RSVG and QT are quite capable and compliant (by far compared to AGG). There is a performance issue with QT though when SVG is fairly complex, where panning and zooming become very slow despite snappy once switched to OpenGL mode. RSVG didn't have this issue and load faster but since it use static build (an unsupported mode in Windows) of GTK-3.4.4 which still not stable for Windows, is unfortunately quite a crasher, also didn't resize its window automatically.
There is one more (better) candidate from Batik's Squiggle but probably too big when compiled and too GUI-ish for a simple viewer. Finally every "sane" modern browser also SVG viewer capable :-)
- SVG Viewer from QT 4.8.2's example (3 MB)
- SVG test from AGG 2.5's demo (178 KB)
- RSVG View from librsvg (2 MB, explicitly need file input, otherwise will silently quit)
It should be static(standalone) as usual, preferably small and must be fast. Both from RSVG and QT are quite capable and compliant (by far compared to AGG). There is a performance issue with QT though when SVG is fairly complex, where panning and zooming become very slow despite snappy once switched to OpenGL mode. RSVG didn't have this issue and load faster but since it use static build (an unsupported mode in Windows) of GTK-3.4.4 which still not stable for Windows
There is one more (better) candidate from Batik's Squiggle but probably too big when compiled and too GUI-ish for a simple viewer. Finally every "sane" modern browser also SVG viewer capable :-)
11 August 2012
Holiday
Been a while since the last post, I'm looking forward for upcoming holiday :). Hopefully there would be a lot of free time (if not spent too much for vacation) for lot of new material/updates to this blog. At the moment I've (more or less) managed to reach my main goal for tuma mingw, this could mean much less attention after version 0.6b and more focus to others such as mypaint, gtk3 and graphics stuff or maybe some delayed chm book releases.
Subscribe to:
Posts (Atom)