docs fix
pandoc changed the name of their top-level section node
This commit is contained in:
John Cupitt
parent
b40baec28b
commit
603036a315
|
|
@ -11,10 +11,10 @@
|
|||
<refnamediv> <refname>Cite</refname> <refpurpose>References to cite for libvips</refpurpose> </refnamediv>
|
||||
</para>
|
||||
<para>
|
||||
Martinez, K. and Cupitt, J. (2005) <ulink url="http://eprints.ecs.soton.ac.uk/12371">VIPS – a highly tuned image processing software architecture</ulink>. In Proceedings of IEEE International Conference on Image Processing 2, pp. 574-577, Genova.
|
||||
Martinez, K. and Cupitt, J. (2005) <link xlink:href="http://eprints.ecs.soton.ac.uk/12371">VIPS – a highly tuned image processing software architecture</link>. In Proceedings of IEEE International Conference on Image Processing 2, pp. 574-577, Genova.
|
||||
</para>
|
||||
<para>
|
||||
Cupitt, J. and Martinez, K. (1996) <ulink url="http://eprints.soton.ac.uk/252227/1/vipsspie96a.pdf">VIPS: An image processing system for large images</ulink>, Proc. SPIE, vol. 2663, pp. 19–28.
|
||||
Cupitt, J. and Martinez, K. (1996) <link xlink:href="http://eprints.soton.ac.uk/252227/1/vipsspie96a.pdf">VIPS: An image processing system for large images</link>, Proc. SPIE, vol. 2663, pp. 19–28.
|
||||
</para>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
<para>
|
||||
The libvips test suite is written in Python and exercises every operation in the API. It’s also a useful source of examples.
|
||||
</para>
|
||||
<refsect3 id="average-a-region-of-interest-box-on-an-image">
|
||||
<refsect3 xml:id="average-a-region-of-interest-box-on-an-image">
|
||||
<title>Average a region of interest box on an image</title>
|
||||
<programlisting language="python">
|
||||
#!/usr/bin/env python
|
||||
|
|
@ -34,7 +34,7 @@ roi = image.crop(left, top, width, height)
|
|||
print 'average:', roi.avg()
|
||||
</programlisting>
|
||||
</refsect3>
|
||||
<refsect3 id="libvips-and-numpy">
|
||||
<refsect3 xml:id="libvips-and-numpy">
|
||||
<title>libvips and numpy</title>
|
||||
<para>
|
||||
You can use <literal>pyvips.Image.new_from_memory()</literal> to make a vips image from an area of memory. The memory array needs to be laid out band-interleaved, as a set of scanlines, with no padding between lines.
|
||||
|
|
@ -113,7 +113,7 @@ vi = pyvips.Image.new_from_memory(linear.data, width, height, bands,
|
|||
vi.write_to_file(sys.argv[2])
|
||||
</programlisting>
|
||||
</refsect3>
|
||||
<refsect3 id="build-huge-image-mosaic">
|
||||
<refsect3 xml:id="build-huge-image-mosaic">
|
||||
<title>Build huge image mosaic</title>
|
||||
<para>
|
||||
This makes a 100,000 x 100,000 black image, then inserts all the images you pass on the command-line into it at random positions. libvips is able to run this program in sequential mode: it’ll open all the input images at the same time, and stream pixels from them as it needs them to generate the output.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
<para>
|
||||
This page tries to explain what the different strategies are and when each is used. If you are running into unexpected memory, disc or CPU use, this might be helpful. <literal>vips_image_new_from_file()</literal> has the official documentation.
|
||||
</para>
|
||||
<section xml:id="direct-access">
|
||||
<refsect3 xml:id="direct-access">
|
||||
<title>Direct access</title>
|
||||
<para>
|
||||
This is the fastest and simplest one. The file is mapped directly into the process’s address space and can be read with ordinary pointer access. Small files are completely mapped; large files are mapped in a series of small windows that are shared and which scroll about as pixels are read. Files which are accessed like this can be read by many threads at once, making them especially quick. They also interact well with the computer’s operating system: your OS will use spare memory to cache recently used chunks of the file.
|
||||
|
|
@ -27,8 +27,8 @@
|
|||
<para>
|
||||
libvips has a special direct write mode where pixels can be written directly to the file image. This is used for the <link xlink:href="libvips-draw.html">draw operators</link>.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="random-access-via-load-library">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="random-access-via-load-library">
|
||||
<title>Random access via load library</title>
|
||||
<para>
|
||||
Some image file formats have libraries which allow true random access to image pixels. For example, libtiff lets you read any tile out of a tiled tiff image very quickly. Because the libraries allow true random access, libvips can simply hook the image load library up to the input of the operation pipeline.
|
||||
|
|
@ -39,8 +39,8 @@
|
|||
<para>
|
||||
libvips can load tiled tiff, tiled OpenEXR, FITS and OpenSlide images in this manner.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="full-decompression">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="full-decompression">
|
||||
<title>Full decompression</title>
|
||||
<para>
|
||||
Many image load libraries do not support random access. In order to use images of this type as inputs to pipelines, libvips has to convert them to a random access format first.
|
||||
|
|
@ -54,8 +54,8 @@
|
|||
<para>
|
||||
This is the slowest and most memory-hungry way to read files, but it’s unavoidable for many file formats. Unless you can use the next one!
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sequential-access">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="sequential-access">
|
||||
<title>Sequential access</title>
|
||||
<para>
|
||||
This a fairly recent addition to libvips and is a hybrid of the previous two.
|
||||
|
|
@ -90,7 +90,7 @@ $ vips shrink fred.png jim.png 10 10
|
|||
<para>
|
||||
This is done automatically in command-line operation. In programs, you need to set <literal>access</literal> to #VIPS_ACCESS_SEQUENTIAL in calls to functions like vips_image_new_from_file().
|
||||
</para>
|
||||
</section>
|
||||
</refsect3>
|
||||
|
||||
|
||||
</refentry>
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ VipsPel *pixel = VIPS_REGION_ADDR( region, x, y );
|
|||
g_object_unref( region );
|
||||
</programlisting>
|
||||
<para>
|
||||
The action that <literal>vips_region_prepare()</literal> takes varies with the type of image. If the image is a file on disc, for example, then VIPS will arrange for a section of the file to be read in.
|
||||
The action that <literal>vips_region_prepare()</literal> takes varies with the type of image. If the image is a file on disc, for example, then VIPS will arrange for a refsect3 of the file to be read in.
|
||||
</para>
|
||||
<para>
|
||||
(* there is an image access mode where you can just use a pointer, but it’s rarely used)
|
||||
|
|
@ -136,7 +136,7 @@ g_object_unref( region );
|
|||
<emphasis role="strong">Data sources</emphasis>
|
||||
</para>
|
||||
<para>
|
||||
VIPS has data sources which can supply pixels for processing from a variety of sources. VIPS can stream images from files in VIPS native format, from tiled TIFF files, from binary PPM/PGM/PBM/PFM, from Radiance (HDR) files, from FITS images and from tiled OpenEXR images. VIPS will automatically unpack other formats to temporary disc files for you but this can obviously generate a lot of disc traffic. It also has a special sequential mode for streaming operations on non-random-access formats. Another section in these docs explains <link xlink:href="How-it-opens-files.md.html">how libvips opens a file</link>. One of the sources uses the <link xlink:href="http://www.imagemagick.org">ImageMagick</link> (or optionally <link xlink:href="http://www.graphicsmagick.org">GraphicsMagick</link> library, so VIPS can read any image format that these libraries can read.
|
||||
VIPS has data sources which can supply pixels for processing from a variety of sources. VIPS can stream images from files in VIPS native format, from tiled TIFF files, from binary PPM/PGM/PBM/PFM, from Radiance (HDR) files, from FITS images and from tiled OpenEXR images. VIPS will automatically unpack other formats to temporary disc files for you but this can obviously generate a lot of disc traffic. It also has a special sequential mode for streaming operations on non-random-access formats. Another refsect3 in these docs explains <link xlink:href="How-it-opens-files.md.html">how libvips opens a file</link>. One of the sources uses the <link xlink:href="http://www.imagemagick.org">ImageMagick</link> (or optionally <link xlink:href="http://www.graphicsmagick.org">GraphicsMagick</link> library, so VIPS can read any image format that these libraries can read.
|
||||
</para>
|
||||
<para>
|
||||
VIPS images are held on disc as a 64-byte header containing basic image information like width, height, bands and format, then the image data as a single large block of pixels, left-to-right and top-to-bottom, then an XML extension block holding all the image metadata, such as ICC profiles and EXIF blocks.
|
||||
|
|
|
|||
|
|
@ -125,10 +125,10 @@ HTML_IMAGES = \
|
|||
$(top_srcdir)/doc/images/Vips-smp.png
|
||||
|
||||
# we have some files in markdown ... convert to docbook for gtk-doc
|
||||
# pandoc makes sect1 headers, we want refsect3 for gtk-doc
|
||||
# pandoc makes section headers, we want refsect3 for gtk-doc
|
||||
.md.xml:
|
||||
pandoc -s --template="$(realpath pandoc-docbook-template.docbook)" --wrap=none -V title="$<" -f markdown+smart -t docbook-smart -o $@ $<
|
||||
sed -e s/sect1/refsect3/g < $@ > x && mv x $@
|
||||
sed -e s/section/refsect3/g < $@ > x && mv x $@
|
||||
|
||||
# Our markdown source files
|
||||
markdown_content_files = \
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
<refnamediv> <refname>Pyramids</refname> <refpurpose>How to use libvips to make image pyramids</refpurpose> </refnamediv>
|
||||
</para>
|
||||
<para>
|
||||
libvips includes <literal>vips_dzsave()</literal>, an operation that can build image pyramids compatible with <ulink url="http://en.wikipedia.org/wiki/Deep_Zoom">DeepZoom</ulink>, Zoomify and <ulink url="https://developers.google.com/maps/">Google Maps</ulink> image viewers. It’s fast and can generate pyramids for large images using only a small amount of memory.
|
||||
libvips includes <literal>vips_dzsave()</literal>, an operation that can build image pyramids compatible with <link xlink:href="http://en.wikipedia.org/wiki/Deep_Zoom">DeepZoom</link>, Zoomify and <link xlink:href="https://developers.google.com/maps/">Google Maps</link> image viewers. It’s fast and can generate pyramids for large images using only a small amount of memory.
|
||||
</para>
|
||||
<para>
|
||||
The TIFF writer, <literal>vips_tiffsave()</literal> can also build tiled pyramidal TIFF images, but that’s very simple to use. This page concentrates on the DeepZoom builder.
|
||||
|
|
@ -64,8 +64,8 @@ operation flags: sequential nocache
|
|||
<para>
|
||||
You can also call <literal>vips_dzsave()</literal> from any language with a libvips binding, or by using <literal>.dz</literal> or <literal>.szi</literal> as an output file suffix.
|
||||
</para>
|
||||
<refsect3 id="writing-deepzoom-pyramids">
|
||||
<title>Writing <ulink url="http://en.wikipedia.org/wiki/Deep_Zoom">DeepZoom</ulink> pyramids</title>
|
||||
<refsect3 xml:id="writing-deepzoom-pyramids">
|
||||
<title>Writing <link xlink:href="http://en.wikipedia.org/wiki/Deep_Zoom">DeepZoom</link> pyramids</title>
|
||||
<para>
|
||||
The <literal>--layout</literal> option sets the basic mode of operation. With no <literal>--layout</literal>, dzsave writes DeepZoom pyramids. For example:
|
||||
</para>
|
||||
|
|
@ -85,7 +85,7 @@ $ vips dzsave huge.tif mydz --suffix .jpg[Q=90]
|
|||
will write JPEG tiles with the quality factor set to 90. You can set any format write options you like, see the API docs for <literal>vips_jpegsave()</literal> for details.
|
||||
</para>
|
||||
</refsect3>
|
||||
<refsect3 id="writing-zoomify-pyramids">
|
||||
<refsect3 xml:id="writing-zoomify-pyramids">
|
||||
<title>Writing Zoomify pyramids</title>
|
||||
<para>
|
||||
Use <literal>--layout zoomify</literal> to put dzsave into zoomify mode. For example:
|
||||
|
|
@ -100,10 +100,10 @@ $ vips dzsave huge.tif myzoom --layout zoomify
|
|||
As with DeepZoom, you can use <literal>--suffix</literal> to set jpeg quality.
|
||||
</para>
|
||||
</refsect3>
|
||||
<refsect3 id="writing-google-maps-pyramids">
|
||||
<title>Writing <ulink url="https://developers.google.com/maps/">Google Maps</ulink> pyramids</title>
|
||||
<refsect3 xml:id="writing-google-maps-pyramids">
|
||||
<title>Writing <link xlink:href="https://developers.google.com/maps/">Google Maps</link> pyramids</title>
|
||||
<para>
|
||||
Use <literal>--layout google</literal> to write Google maps-style pyramids. These are compatible with <ulink url="http://leafletjs.com/">leaflet</ulink>. For example:
|
||||
Use <literal>--layout google</literal> to write Google maps-style pyramids. These are compatible with <link xlink:href="http://leafletjs.com/">leaflet</link>. For example:
|
||||
</para>
|
||||
<programlisting>
|
||||
$ vips dzsave wtc.tif gmapdir --layout google
|
||||
|
|
@ -127,7 +127,7 @@ $ vips dzsave wtc.tif gmapdir --layout google
|
|||
$ vips dzsave wtc.tif gmapdir --layout google --background 0 --centre
|
||||
</programlisting>
|
||||
</refsect3>
|
||||
<refsect3 id="other-options">
|
||||
<refsect3 xml:id="other-options">
|
||||
<title>Other options</title>
|
||||
<para>
|
||||
You can use <literal>--tile-size</literal> and <literal>--overlap</literal> to control how large the tiles are and how they overlap (obviously). They default to the correct values for the selected layout.
|
||||
|
|
@ -151,7 +151,7 @@ $ vips dzsave wtc.tif mypyr.zip
|
|||
Use <literal>--properties</literal> to output an XML file called <literal>vips-properties.xml</literal>. This contains a dump of all the metadata vips has about the image as a set of name-value pairs. It’s handy with openslide image sources.
|
||||
</para>
|
||||
</refsect3>
|
||||
<refsect3 id="preprocessing-images">
|
||||
<refsect3 xml:id="preprocessing-images">
|
||||
<title>Preprocessing images</title>
|
||||
<para>
|
||||
You can use <literal>.dz</literal> as a filename suffix, meaning send the image to <literal>vips_dzsave()</literal>. This means you can write the output of any vips operation to a pyramid. For example:
|
||||
|
|
@ -172,7 +172,7 @@ $ vips dzsave CMU-1.mrxs[level=1] x
|
|||
Will pull out level 1 (the half-resolution level of an MRXS slide) and make a pyramid from that.
|
||||
</para>
|
||||
</refsect3>
|
||||
<refsect3 id="troubleshooting">
|
||||
<refsect3 xml:id="troubleshooting">
|
||||
<title>Troubleshooting</title>
|
||||
<para>
|
||||
If you are building vips from source you do need to check the summary at the end of configure carefully. You must have the <literal>libgsf-1-dev</literal> package for <literal>vips_dzsave()</literal> to work.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ $filename = "image.jpg";
|
|||
$image = Vips\Image::thumbnail($filename, 200, ["height" => 200]);
|
||||
$image->writeToFile("my-thumbnail.jpg");
|
||||
</programlisting>
|
||||
<section xml:id="libvips-options">
|
||||
<refsect3 xml:id="libvips-options">
|
||||
<title>libvips options</title>
|
||||
<para>
|
||||
<literal>vipsthumbnail</literal> supports the usual range of vips command-line options. A few of them are useful:
|
||||
|
|
@ -38,8 +38,8 @@ $image->writeToFile("my-thumbnail.jpg");
|
|||
<para>
|
||||
<literal>--vips-info</literal> shows a higher level view of the operations that <literal>vipsthumbnail</literal> is running.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="looping">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="looping">
|
||||
<title>Looping</title>
|
||||
<para>
|
||||
<literal>vipsthumbnail</literal> can process many images in one command. For example:
|
||||
|
|
@ -48,7 +48,7 @@ $image->writeToFile("my-thumbnail.jpg");
|
|||
$ vipsthumbnail *.jpg
|
||||
</programlisting>
|
||||
<para>
|
||||
will make a thumbnail for every jpeg in the current directory. See the <link linkend="output-directory">Output directory</link> section below to see how to change where thumbnails are written.
|
||||
will make a thumbnail for every jpeg in the current directory. See the <link linkend="output-directory">Output directory</link> refsect3 below to see how to change where thumbnails are written.
|
||||
</para>
|
||||
<para>
|
||||
<literal>vipsthumbnail</literal> will process images one after the other. You can get a good speedup by running several <literal>vipsthumbnail</literal>s in parallel, depending on how much load you want to put on your system. For example:
|
||||
|
|
@ -56,8 +56,8 @@ $ vipsthumbnail *.jpg
|
|||
<programlisting>
|
||||
$ parallel vipsthumbnail ::: *.jpg
|
||||
</programlisting>
|
||||
</section>
|
||||
<section xml:id="thumbnail-size">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="thumbnail-size">
|
||||
<title>Thumbnail size</title>
|
||||
<para>
|
||||
You can set the bounding box of the generated thumbnail with the <literal>--size</literal> option. For example:
|
||||
|
|
@ -80,8 +80,8 @@ $ vipsthumbnail shark.jpg --size 200x
|
|||
<para>
|
||||
You can append <literal>!</literal> to force a resize to the exact target size, breaking the aspect ratio.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="cropping">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="cropping">
|
||||
<title>Cropping</title>
|
||||
<para>
|
||||
<literal>vipsthumbnail</literal> normally shrinks images to fit within the box set by <literal>--size</literal>. You can use the <literal>--smartcrop</literal> option to crop to fill the box instead. Excess pixels are trimmed away using the strategy you set. For example:
|
||||
|
|
@ -112,8 +112,8 @@ $ vipsthumbnail owl.jpg --smartcrop attention -s 128
|
|||
<para>
|
||||
First it shrinks the image to get the vertical axis to 128 pixels, then crops down to 128 pixels across using the <literal>attention</literal> strategy. This one searches the image for features which might catch a human eye, see <literal>vips_smartcrop()</literal> for details.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="linear-light">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="linear-light">
|
||||
<title>Linear light</title>
|
||||
<para>
|
||||
Shrinking images involves combining many pixels into one. Arithmetic averaging really ought to be in terms of the number of photons, but (for historical reasons) the values stored in image files are usually related to the voltage that should be applied to the electron gun in a CRT display.
|
||||
|
|
@ -140,8 +140,8 @@ real 0m4.660s
|
|||
user 0m4.640s
|
||||
sys 0m0.016s
|
||||
</programlisting>
|
||||
</section>
|
||||
<section xml:id="output-directory">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="output-directory">
|
||||
<title>Output directory</title>
|
||||
<para>
|
||||
You set the thumbnail write parameters with the <literal>-o</literal> option. This is a pattern which the input filename is pasted into to produce the output filename. For example:
|
||||
|
|
@ -170,8 +170,8 @@ $ vipsthumbnail fred.jpg ../jim.tif -o mythumbs/tn_%s.jpg
|
|||
<para>
|
||||
Now both input files will have thumbnails written to a subdirectory of their current directory.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="output-format-and-options">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="output-format-and-options">
|
||||
<title>Output format and options</title>
|
||||
<para>
|
||||
You can use <literal>-o</literal> to specify the thumbnail image format too. For example:
|
||||
|
|
@ -245,8 +245,8 @@ $ vipsthumbnail 42-32157534.jpg -o x.jpg[optimize_coding,strip]
|
|||
$ ls -l x.jpg
|
||||
-rw-r–r– 1 john john 3600 Nov 12 21:27 x.jpg
|
||||
</programlisting>
|
||||
</section>
|
||||
<section xml:id="colour-management">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="colour-management">
|
||||
<title>Colour management</title>
|
||||
<para>
|
||||
<literal>vipsthumbnail</literal> will optionally put images through LittleCMS for you. You can use this to move all thumbnails to the same colour space. All web browsers assume that images without an ICC profile are in sRGB colourspace, so if you move your thumbnails to sRGB, you can strip all the embedded profiles. This can save several kb per thumbnail.
|
||||
|
|
@ -290,8 +290,8 @@ $ vipsthumbnail kgdev.jpg --iprofile cmyk
|
|||
<para>
|
||||
(As before, the magic string <literal>cmyk</literal> selects a high-quality CMYK profile that’s built into libvips, but you can use any CMYK profile you like.)
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="final-suggestion">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="final-suggestion">
|
||||
<title>Final suggestion</title>
|
||||
<para>
|
||||
Putting all this together, I suggest this as a sensible set of options:
|
||||
|
|
@ -303,7 +303,7 @@ $ vipsthumbnail fred.jpg \
|
|||
-o tn_%s.jpg[optimize_coding,strip] \
|
||||
--eprofile srgb
|
||||
</programlisting>
|
||||
</section>
|
||||
</refsect3>
|
||||
|
||||
|
||||
</refentry>
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
<para>
|
||||
This chapter runs through the four main styles that have been found to work well. If you want to write a new binding, one of these should be close to what you need.
|
||||
</para>
|
||||
<section xml:id="dont-bind-the-top-level-c-api">
|
||||
<refsect3 xml:id="dont-bind-the-top-level-c-api">
|
||||
<title>Don’t bind the top-level C API</title>
|
||||
<para>
|
||||
The libvips C API (vips_add() and so on) is very inconvenient and dangerous to use from other languages due to its heavy use of varargs.
|
||||
|
|
@ -117,8 +117,8 @@ main( int argc, char **argv )
|
|||
<para>
|
||||
Use vips_operation_get_flags() to get general information about an operator.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="compiled-language-which-can-call-c">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="compiled-language-which-can-call-c">
|
||||
<title>Compiled language which can call C</title>
|
||||
<para>
|
||||
The C++ binding uses this lower layer to define a function called <literal>VImage::call()</literal> which can call any libvips operator with a not-varargs set of variable arguments.
|
||||
|
|
@ -144,8 +144,8 @@ VImage VImage::invert( VOption *options )
|
|||
<para>
|
||||
The <literal>VImage</literal> class also adds automatic reference counting, constant expansion, operator overloads, and various other useful features.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="dynamic-language-with-ffi">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="dynamic-language-with-ffi">
|
||||
<title>Dynamic language with FFI</title>
|
||||
<para>
|
||||
Languages like Ruby, Python, JavaScript and LuaJIT can’t call C directly, but they do support FFI. The bindings for these languages work rather like C++, but use FFI to call into libvips and run operations.
|
||||
|
|
@ -153,14 +153,14 @@ VImage VImage::invert( VOption *options )
|
|||
<para>
|
||||
Since these languages are dynamic, they can add another trick: they intercept the method-missing hook and attempt to run any method calls not implemented by the <literal>Image</literal> class as libvips operators. This makes these bindings self-writing: they only contain a small amount of code and just expose everything they find in the libvips class hierarchy.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="dynamic-langauge-without-ffi">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="dynamic-langauge-without-ffi">
|
||||
<title>Dynamic langauge without FFI</title>
|
||||
<para>
|
||||
PHP does not have FFI, unfortunately, so for this language a small native module implements the general <literal>vips_call()</literal> function for PHP language types, and a larger pure PHP layer makes it convenient to use.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="gobject-introspection">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="gobject-introspection">
|
||||
<title>gobject-introspection</title>
|
||||
<para>
|
||||
The C source code to libvips has been marked up with special comments describing the interface in a standard way. These comments are read by the <literal>gobject-introspection</literal> package when libvips is compiled and used to generate a typelib, a description of how to call the library. Many languages have gobject-introspection packages: all you need to do to call libvips from your favorite language is to start g-o-i, load the libvips typelib, and you should have the whole library available. For example, from Python it’s as simple as:
|
||||
|
|
@ -177,8 +177,8 @@ from gi.repository import Vips
|
|||
<para>
|
||||
If you have a choice, I would recommend simply using FFI.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="documentation">
|
||||
</refsect3>
|
||||
<refsect3 xml:id="documentation">
|
||||
<title>Documentation</title>
|
||||
<para>
|
||||
You can generate searchable docs from a <code>.gir</code> (the thing that is built from scanning libvips and which in turn turn the typelib is made from) with <command>g-ir-doc-tool</command>, for example:
|
||||
|
|
@ -202,7 +202,7 @@ $ yelp-build html .
|
|||
<para>
|
||||
To make HTML docs. This is an easy way to see what you can call in the library.
|
||||
</para>
|
||||
</section>
|
||||
</refsect3>
|
||||
|
||||
|
||||
</refentry>
|
||||
|
|
|
|||
Loading…
Reference in New Issue