VipsWiki - Recent changes [en]

Build on OS X

John — Mon, 20 May 2013 10:01:35 GMT

/* Homebrew */

Revision as of 10:01, 20 May 2013		Current revision
Line 10:		Line 10:

	<pre>		<pre>
		+	$ brew tap homebrew/science
	$ brew install vips		$ brew install vips
		+	</pre>
		+
		+	To verify your vips install, try:
		+
		+	<pre>
		+	$ vips --version
		+	vips-7.32.1-Mon May 20 10:01:38 BST 2013
	</pre>		</pre>

	This is a good way to get libvips on your system, not so great for nip2.		This is a good way to get libvips on your system, not so great for nip2.
		+
		+	This will give you a very bare-bones vips, missing things like imagemagick loading, openslide support, FFTs, and so on. To get a list of all the optional dependencies, try:
		+
		+	<pre>
		+	$ brew info vips
		+	</pre>
		+
		+	For a full-fat version, try:
		+
		+	<pre>
		+	$ brew install vips --with-cfitsio --with-fftw --with-imagemagick \
		+	--with-libexif --with-liboil --with-libtiff --with-little-cms \
		+	--with-openexr --with-openslide --with-pango
		+	</pre>
		+
		+	If you want to build things outside homebrew which depend on vips, such as ruby-vips, you will need to get your pkg-config working. You need to point pkg-config at the homebrew area, and, additionally, at homebrew's libxml2 area:
		+
		+	In your .profile, add something like:
		+
		+	<pre>
		+	export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/opt/libxml2/lib/pkgconfig
		+	</pre>
		+
		+	To verify that pkg-config is working correctly with vips, try:
		+
		+	<pre>
		+	$ pkg-config vips --libs
		+	-L/usr/local/Cellar/vips/7.32.1/lib ... a lot of stuff
		+	</pre>

	=== Macports ===		=== Macports ===

	VIPS and nip2 are in [http://www.macports.org/ Macports], though it's an old version.		VIPS and nip2 are in [http://www.macports.org/ Macports], though it's an old version.

How it works

John — Fri, 17 May 2013 12:48:24 GMT

/* Partial images */

Revision as of 12:48, 17 May 2013		Current revision
Line 53:		Line 53:
	The stored function comes in three parts: a start function, a generate function and a stop function. The start function creates a state, the generate function uses the state plus a requested area to calculate pixel values and the stop function frees the state again. Breaking the stored function into three parts is good for SMP scaling: resource allocation and synchronisation mostly happens in start functions, so generate functions can run without having to talk to each other.		The stored function comes in three parts: a start function, a generate function and a stop function. The start function creates a state, the generate function uses the state plus a requested area to calculate pixel values and the stop function frees the state again. Breaking the stored function into three parts is good for SMP scaling: resource allocation and synchronisation mostly happens in start functions, so generate functions can run without having to talk to each other.

-	VIPS makes a set of guarantees about parallelism that make this simple to program. Start and stop functions are mutually exclusive and a state is never be used by more than one generate. In other words, a start / generate / generate / stop sequence works like a thread.	+	VIPS makes a set of guarantees about parallelism that make this simple to program. Start and stop functions are mutually exclusive and a state is never used by more than one generate. In other words, a start / generate / generate / stop sequence works like a thread.

	[[Image:Sequence.png]]		[[Image:Sequence.png]]

Speed and Memory Use

John — Fri, 17 May 2013 11:27:21 GMT

/* Why is VIPS quick */

Revision as of 11:27, 17 May 2013		Current revision
Line 67:		Line 67:

	ImageScience is based on FreeImage and therefore does not support sharpening, so I've skipped that part of the test. The '''resize()''' method is always bicubic which is a little unfair as the other benchmarks here use bilinear.		ImageScience is based on FreeImage and therefore does not support sharpening, so I've skipped that part of the test. The '''resize()''' method is always bicubic which is a little unfair as the other benchmarks here use bilinear.
		+
		+	=== Why is VIPS quick ===
		+
		+	We have a [[How it works]] page which goes into some detail, but briefly:
		+
		+	; Threaded image input-output (IO) system: Most image processing libraries have threaded operations. Each operation has code, generally using a framework like OpenMP, to run the operation over all the available processors. VIPS instead puts the threading into the image IO system, so all operations are automatically threaded. Additionally, this type of "horizontal" threading makes much better use of processor caches and dramatically reduces the amount of locking you need.
		+
		+	; Fast operations: The VIPS primitives are implemented carefully, and some use techniques like run-time code generation. The convolution operator, for example, will examine the matrix and the image and write a short SSE3 program to implement exactly that convolution on exactly that image.
		+
		+	; Demand-driven: VIPS is fully demand-driven, so it only needs to keep a few pixel buffers in memory, it doesn't need to load the whole image. This reduces memory use.

	== Implementations ==		== Implementations ==
Line 254:		Line 264:
	</pre>		</pre>

-	=== ExactImage ===	+	=== [http://www.exactcode.com/site/open_source/exactimage/ ExactImage] ===

	<pre>		<pre>

How it works

John — Wed, 24 Apr 2013 09:01:43 GMT

/* Operations */

Revision as of 09:01, 24 April 2013		Current revision
Line 64:		Line 64:

	Like most threaded image processing systems, all VIPS operations have to be free of side-effects. In other words, operations cannot modify images, they can only create new images. This could result in a lot of copying if an operation is only making a small change to a large image so VIPS has a set of mechanisms to copy image areas by just adjusting pointers. Most of the time no actual copying is necessary and you can perform operations on large images at low cost.		Like most threaded image processing systems, all VIPS operations have to be free of side-effects. In other words, operations cannot modify images, they can only create new images. This could result in a lot of copying if an operation is only making a small change to a large image so VIPS has a set of mechanisms to copy image areas by just adjusting pointers. Most of the time no actual copying is necessary and you can perform operations on large images at low cost.
		+
		+	=== Run-time code generation ===
		+
		+	VIPS uses [http://code.entropywave.com/orc/ Orc], a run-time compiler, to generate code for some operations. For example, to compute a convolution on an 8-bit image, VIPS will examine the convolution matrix and the source image and generate a tiny program to calculate the convolution. This program is then "compiled" to the vector instruction set for your CPU, for example SSE2 on most x86 processors.
		+
		+	Run-time vector code generation typically speeds operations up by a factor of three or four.

	=== Joining operations together ===		=== Joining operations together ===

Speed and Memory Use

John — Wed, 24 Apr 2013 08:27:45 GMT

/* GraphicsMagick */

Revision as of 08:27, 24 April 2013		Current revision
Line 27:		Line 27:
	\|-		\|-
	\| RMagick 2.13.2 (ImageMagick 6.7.7.10-2ubuntu4) \|\| 1.98 \|\| 670 \|\| 6.00		\| RMagick 2.13.2 (ImageMagick 6.7.7.10-2ubuntu4) \|\| 1.98 \|\| 670 \|\| 6.00
		+	\|-
		+	\| ExactImage 0.8.5 \|\| 2.13 \|\| 110 \|\| 6.4
	\|-		\|-
	\| ImageMagick 6.7.7.10-2ubuntu4 \|\| 2.46 \|\| 480 \|\| 7.45		\| ImageMagick 6.7.7.10-2ubuntu4 \|\| 2.46 \|\| 480 \|\| 7.45
Line 57:		Line 59:

	The VIPS command-line generates a huge amount of disc traffic which makes it unsuitable in certain applications. This is not really considered in this table.		The VIPS command-line generates a huge amount of disc traffic which makes it unsuitable in certain applications. This is not really considered in this table.
		+
		+	ExactImage will not read tiled tiff, so the benchmark uses a strip tiff for this test.

	Octave aims to be a very high-level prototyping language and is not primarily targeting speed. I timed a 2,000 by 2,000 pixel monochrome JPEG and extrapolated from that.		Octave aims to be a very high-level prototyping language and is not primarily targeting speed. I timed a 2,000 by 2,000 pixel monochrome JPEG and extrapolated from that.
Line 248:		Line 252:
	-convolve "-1, -1, -1, -1, 16, -1, -1, -1, -1" \		-convolve "-1, -1, -1, -1, 16, -1, -1, -1, -1" \
	$2		$2
		+	</pre>
		+
		+	=== ExactImage ===
		+
		+	<pre>
		+	#!/bin/bash
		+
		+	width=`header -f Xsize $1`
		+	height=`header -f Ysize $1`
		+
		+	width=$((width - 200))
		+	height=$((height - 200))
		+
		+	# set -x
		+
		+	econvert -i $1 \
		+	--crop "100,100,$width,$height" \
		+	--bilinear-scale 0.9 \
		+	--convolve "-1, -1, -1, -1, 16, -1, -1, -1, -1" \
		+	-o $2
	</pre>		</pre>