Windows/Linux/OSX ImageMagick GUI

[NicolasRobidoux]

News from John Cupitt, lead dev of NIP2 (New Image Processor 2) http://www.vips.ecs.soton.ac.uk/index.php?title=Nip2 the GUI of the graphics library libvips, but also now for several ImageMagick operations:

Hi Nicolas,

I've just put up nip2 7.40.2:

http://www.vips.ecs.soton.ac.uk/support ... -setup.zip

This time the IM stuff really does work on Windows, I've spent some
time tuning it with an actual Windows machine.

See http://libvips.blogspot.dk/2011/06/usin ... -nip2.html.
-----
Many thanks to him and Alan Gibson (a.k.a. snibgo), who ported the ImageMagick operations.

[jcupitt]

It's actually the whole of convert. Hopefully anything you can do on the command-line you can do with a menu.

On Windows you get a very annoying command window flash up briefly each time it runs convert.exe which I've not figured out how to hide, but otherwise it all should work.

The Magick menu is mostly just a very long list right now, it should really be organised into a nice tree. You can use the toolkit browser to make it a bit less indigestible: click View / Toolkit Browser, then type (for example) "chop" into the search box. Doubleclick on the chop line to run that operation.

[NicolasRobidoux]

What can I say besides "\o/"?

[NicolasRobidoux]

John:
Would you consider making the IM version that's bundled with NIP2 be the floating point (HDRI) one by default?
This, I think, would be quite attractive to many users.

[jcupitt]

I guess so. Would it hurt performance badly? Will it try to load and save as 32-bit float tiff? I'd think there would be at least a x2 speed cost, and it's rather slow already.

[NicolasRobidoux]

Off the top of my head:
Load/save format is a separate thing from what it uses to compute internally: http://www.imagemagick.org/Usage/basics/#hdri_formats.
It most likely will affect speed. I don't think x2, however, if you bundle with IM7. A small factor, esp. if you compile IM with optimizing flags (off the top of my head, the standard optimization flags are rather tame, for portability I imagine; may have changed).
However some operations give better results going through floating point. Orthogonal (tensor) resampling filters (like standard lanczos), sigmoidal contrast, probably others. Not sure about usual colorspace transformations. I am a big fan of radical gamma mappings, and I would guess non-HDRI is asking for trouble.
Also see http://www.imagemagick.org/Usage/basics/#hdri.
I never use non-HDRI if I have the choice or do anything nontrivial. But that's me.

[fmw42]

Just a point of interest. In HDRI mode, one can save image with negative values and fraction values by using PFM or TIFF (MIFF or MPC). Other formats will only be save to integers. Also some features of FFT that use real/imaginary components rather than magnitude/phase components require HDRI mode. I think the main issue is it uses more memory. Internally IM processes as doubles, but clips to non-negative integers between functions. In HDRI mode, I believe floats are maintained.

[NicolasRobidoux]

Will it try to load and save as 32-bit float tiff?

Whatever it loads (unless a depth command is issued?) will generally be stored, internally, in a floating point format. If this is not acceptable, stick to the standard Q16 version.
There may be ways of controlling this behavior, but I don't have time to look into this now.

[fmw42]

Will it try to load and save as 32-bit float tiff?

To save as float TIFF (and MIFF), you need to add the following define

"To specify a single-precision floating-point format, use -define quantum:format=floating-point. Set the depth to 64 for a double-precision floating-point format."

PFM and MPC will automatically store to float. All other formats save as (non-negative) integer.

[Kembreg]

I downloaded it, installted and ran it.

Found it so utterly confusing I uninstalled it.

Quite disappointing.