sergiotarxz/libvips
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fix small things

Browse Source
This commit is contained in:
John Cupitt 2017-03-31 20:15:33 +01:00
parent b2b95ca045
commit bc247770f4
5 changed files with 92 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
doc/How-it-works.md
View File

@ -4,7 +4,7 @@ improvement by only keeping the pixels currently being processed in RAM
and by having an efficient, threaded image IO system. This page explains
how these features are implemented.
### Images
# Images
VIPS images have three dimensions: width, height and bands. Bands usually
(though not always) represent colour. These three dimensions can be any
@ -12,7 +12,7 @@ size up to 2 ** 31 elements. Every band element in an image has to have the
same format. A format is an 8-, 16- or 32-bit int, signed or unsigned, 32-
or 64-bit float, and 64- or 128-bit complex.
### Regions
# Regions
An image can be very large, much larger than the available memory, so you
can't just access pixels with a pointer \*.
@ -54,7 +54,7 @@ for a section of the file to be read in.
(\* there is an image access mode where you can just use a pointer, but
it's rarely used)
### Partial images
# Partial images
A partial image is one where, instead of storing a value for each pixel, VIPS
stores a function which can make any rectangular area of pixels on demand.
@ -81,7 +81,7 @@ generate / stop sequence works like a thread.
(\* in fact VIPS keeps a cache of calculated pixel buffers and will return
a pointer to a previously-calculated buffer if it can)
### Operations
# Operations
VIPS operations read input images and write output images, performing some
transformation on the pixels. When an operation writes to an image the
@ -98,7 +98,7 @@ 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
# Run-time code generation
VIPS uses [Orc](http://code.entropywave.com/orc/), a run-time compiler, to
generate code for some operations. For example, to compute a convolution
@ -110,7 +110,7 @@ SSE3 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
The region create / prepare / prepare / free calls you use to get pixels
from an image are an exact parallel to the start / generate / generate /
@ -143,7 +143,7 @@ each thread runs a very cheap copy of just the writeable state of the
entire pipeline, threads can run with few locks. VIPS needs just four lock
operations per output tile, regardless of the pipeline length or complexity.
### Data sources
# Data sources
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
@ -171,7 +171,7 @@ are demanded by different threads VIPS will move these windows up and down
the file. As a result, VIPS can process images much larger than RAM, even
on 32-bit machines.
### Data sinks
# Data sinks
In a demand-driven system, something has to do the demanding. VIPS has a
variety of data sinks that you can use to pull image data though a pipeline
@ -210,7 +210,7 @@ ensure that there are at least two tiles for every thread)
(\*\* tiles can be any shape and size, VIPS has a tile hint system that
operations use to tell sinks what tile geometry they prefer)
### Operation cache
# Operation cache
Because VIPS operations are free of side-effects\*, you can cache them. Every
time you call an operation, VIPS searches the cache for a previous call to
@ -225,7 +225,7 @@ the cache size by memory use or by files opened.
"invalidate" signal on the image they are called on and this signal makes
all downstream operations and caches drop their contents.)
### Operation database and APIs
# Operation database and APIs
VIPS has around 300 image processing operations written in this style. Each
operation is a GObject class. You can use the standard GObject calls to walk
@ -243,7 +243,7 @@ gobject-introspection. It is written in Python, so as long as you can get
gobject-introspection working, you should be able to use vips. It supports
python2 and python3 and works on Linux, OS X and Windows.
### Snip
# Snip
The VIPS GUI, nip2, has its own scripting language called Snip. Snip is a
lazy, higher-order, purely functional, object oriented language. Almost all

12
doc/Making-image-pyramids.md
View File

@ -55,7 +55,7 @@ operation flags: sequential nocache
You can also call `vips_dzsave()` from any language with a libvips binding, or
by using `.dz` or `.szi` as an output file suffix.
### Writing [DeepZoom](http://en.wikipedia.org/wiki/Deep_Zoom) pyramids
# Writing [DeepZoom](http://en.wikipedia.org/wiki/Deep_Zoom) pyramids
The `--layout` option sets the basic mode of operation. With no
`--layout`, dzsave writes DeepZoom pyramids. For example:
@ -79,7 +79,7 @@ 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 `vips_jpegsave()`
for details.
### Writing Zoomify pyramids
# Writing Zoomify pyramids
Use `--layout zoomify` to put dzsave into zoomify mode. For example:
@ -93,7 +93,7 @@ directories called `TileGroupn`, each containing 256 image tiles.
As with DeepZoom, you can use `--suffix` to set jpeg quality.
### Writing [Google Maps](https://developers.google.com/maps/) pyramids
# Writing [Google Maps](https://developers.google.com/maps/) pyramids
Use `--layout google` to write Google maps-style pyramids. These are
compatible with the [NYU Pathology pyramid
@ -125,7 +125,7 @@ For example:
$ vips dzsave wtc.tif gmapdir --layout google --background 0 --centre
```
#### Other options
# Other options
You can use `--tile-size` and `--overlap` to control how large the tiles
are and how they overlap (obviously). They default to the correct values
@ -157,7 +157,7 @@ Use `--properties` to output an XML file called `vips-properties.xml`. 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.
#### Preprocessing images
# Preprocessing images
You can use `.dz` as a filename suffix, meaning send the image to
`vips_dzsave()`. This means you can write the output of any vips operation to a
@ -182,7 +182,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.
#### Troubleshooting
# Troubleshooting
If you are building vips from source you do need to check the summary at
the end of configure carefully. You must have the `libgsf-1-dev` package

90
doc/Making-image-pyramids.xml
View File

@ -131,57 +131,57 @@ $ vips dzsave wtc.tif gmapdir --layout google
<programlisting>
$ vips dzsave wtc.tif gmapdir --layout google --background 0 --centre
</programlisting>
<sect2 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.
</para>
<para>
You can use <literal>--depth</literal> to control how deep the pyramid should be. Possible values are <literal>onepixel</literal>, <literal>onetile</literal> and <literal>one</literal>. <literal>onepixel</literal> means the image is shrunk until it fits within a single pixel. <literal>onetile</literal> means shrink until it fits with a tile. <literal>one</literal> means only write one pyramid layer (the highest resolution one). It defaults to the correct value for the selected layout. <literal>--depth one</literal> is handy for slicing up a large image into tiles (rather than a pyramid).
</para>
<para>
You can use <literal>--angle</literal> to do a 90, 180 or 270 degree rotate of an image during pyramid write.
</para>
<para>
You can use <literal>--container</literal> to set the container type. Normally dzsave will write a tree of directories, but with <literal>--container zip</literal> you’ll get a zip file instead. Use .zip as the directory suffix to turn on zip format automatically:
</para>
<programlisting>
</refsect3>
<refsect3 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.
</para>
<para>
You can use <literal>--depth</literal> to control how deep the pyramid should be. Possible values are <literal>onepixel</literal>, <literal>onetile</literal> and <literal>one</literal>. <literal>onepixel</literal> means the image is shrunk until it fits within a single pixel. <literal>onetile</literal> means shrink until it fits with a tile. <literal>one</literal> means only write one pyramid layer (the highest resolution one). It defaults to the correct value for the selected layout. <literal>--depth one</literal> is handy for slicing up a large image into tiles (rather than a pyramid).
</para>
<para>
You can use <literal>--angle</literal> to do a 90, 180 or 270 degree rotate of an image during pyramid write.
</para>
<para>
You can use <literal>--container</literal> to set the container type. Normally dzsave will write a tree of directories, but with <literal>--container zip</literal> you’ll get a zip file instead. Use .zip as the directory suffix to turn on zip format automatically:
</para>
<programlisting>
$ vips dzsave wtc.tif mypyr.zip
</programlisting>
<para>
to write a zipfile containing the tiles. You can use <literal>.szi</literal> as a suffix to enable zip output as well.
</para>
<para>
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>
</sect2>
<sect2 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:
</para>
<programlisting>
<para>
to write a zipfile containing the tiles. You can use <literal>.szi</literal> as a suffix to enable zip output as well.
</para>
<para>
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">
<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:
</para>
<programlisting>
$ vips extract_area huge.svs mypy.dz[layout=google] 100 100 10000 10000
</programlisting>
<para>
The arguments to <literal>extract_area</literal> are image-in, image-out, left, top, width, height. So this command will cut out a 10,000 by 10,000 pixel area from near the top-left-hand corner of an Aperio slide image, then build a pyramid in Google layout using just those pixels.
</para>
<para>
If you are working from OpenSlide images, you can use the shrink-on-load feature of many of those formats. For example:
</para>
<programlisting>
<para>
The arguments to <literal>extract_area</literal> are image-in, image-out, left, top, width, height. So this command will cut out a 10,000 by 10,000 pixel area from near the top-left-hand corner of an Aperio slide image, then build a pyramid in Google layout using just those pixels.
</para>
<para>
If you are working from OpenSlide images, you can use the shrink-on-load feature of many of those formats. For example:
</para>
<programlisting>
$ vips dzsave CMU-1.mrxs[level=1] x
</programlisting>
<para>
Will pull out level 1 (the half-resolution level of an MRXS slide) and make a pyramid from that.
</para>
</sect2>
<sect2 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.
</para>
</sect2>
<para>
Will pull out level 1 (the half-resolution level of an MRXS slide) and make a pyramid from that.
</para>
</refsect3>
<refsect3 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.
</para>
</refsect3>

20
doc/Using-vipsthumbnail.md
View File

@ -6,7 +6,7 @@ The thumbnailing functionality is implemeted by
`vips_thumbnail_buffer()`, see the docs for details. You can use these
functions from any language with a libvips binding.
### libvips options
# libvips options
`vipsthumbnail` supports the usual range of vips command-line options. A
few of them are useful:
@ -23,7 +23,7 @@ useful to see where libvips is looping and how often.
`--vips-info` shows a higher level view of the operations that `vipsthumbnail`
is running. 
### Looping
# Looping
vipsthumbnail can process many images in one operation. For example:
@ -43,7 +43,7 @@ much load you want to put on your system. For example:
$ parallel vipsthumbnail ::: *.jpg
```
### Thumbnail size
# Thumbnail size
You can set the bounding box of the generated thumbnail with the `--size`
option. For example:
@ -65,7 +65,7 @@ is.
You can append `<` or `>` to mean only resize if the image is smaller or larger
than the target.
### Cropping
# Cropping
`vipsthumbnail` normally shrinks images to fit within the box set by `--size`.
You can use the `--smartcrop` option to crop to fill the box instead. Excess
@ -88,7 +88,7 @@ down to 128 pixels across using the `attention` strategy. This one searches
the image for features which might catch a human eye, see `vips_smartcrop()`
for details.
### Linear light
# Linear light
Shrinking images involves combining many pixels into one. Arithmetic
averaging really ought to be in terms of the number of photons, but (for
@ -108,7 +108,7 @@ done by the image libraries is done at encode time, and done in
terms of CRT voltage, not light. This can make linear light thumbnailing of
large images extremely slow.
### Output directory
# Output directory
You set the thumbnail write parameters with the `-o`
option. This is a pattern which the input filename is pasted into to
@ -147,7 +147,7 @@ $ vipsthumbnail fred.jpg ../jim.tif -o mythumbs/tn_%s.jpg
Now both input files will have thumbnails written to a subdirectory of
their current directory.
### Output format and options
# Output format and options
You can use `-o`
to specify the thumbnail image format too. For example: 
@ -224,7 +224,7 @@ $ ls -l x.jpg
-rw-r–r– 1 john john 3600 Nov 12 21:27 x.jpg
```
### Colour management
# Colour management
`vipsthumbnail` will optionally put images through LittleCMS for you. You can
use this to move all thumbnails to the same colour space. All web browsers
@ -253,7 +253,7 @@ It’ll look identical to a user, but be almost half the size.
You can also specify a fallback input profile to use if the image has no
embedded one, but this is less useful.
### Auto-rotate
# Auto-rotate
Many JPEG files have a hint set in the header giving the image orientation. If
you strip out the metadata, this hint will be lost, and the image will appear
@ -262,7 +262,7 @@ to be rotated.
If you use the `--rotate` option, `vipsthumbnail` examines the image header and
if there's an orientation tag, applies and removes it.
### Final suggestion
# Final suggestion
Putting all this together, I suggest this as a sensible set of options:

40
doc/Using-vipsthumbnail.xml
View File

@ -21,7 +21,7 @@
<para>
The thumbnailing functionality is implemeted by <literal>vips_thumbnail()</literal> and <literal>vips_thumbnail_buffer()</literal>, see the docs for details. You can use these functions from any language with a libvips binding.
</para>
<refsect3 id="libvips-options">
<refsect2 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 @@
<para>
<literal>--vips-info</literal> shows a higher level view of the operations that <literal>vipsthumbnail</literal> is running. 
</para>
</refsect3>
<refsect3 id="looping">
</refsect2>
<refsect2 id="looping">
<title>Looping</title>
<para>
vipsthumbnail can process many images in one operation. For example:
@ -56,8 +56,8 @@ $ vipsthumbnail *.jpg
<programlisting>
$ parallel vipsthumbnail ::: *.jpg
</programlisting>
</refsect3>
<refsect3 id="thumbnail-size">
</refsect2>
<refsect2 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:
@ -77,8 +77,8 @@ $ vipsthumbnail shark.jpg --size 200x
<para>
You can append <literal>&lt;</literal> or <literal>&gt;</literal> to mean only resize if the image is smaller or larger than the target.
</para>
</refsect3>
<refsect3 id="cropping">
</refsect2>
<refsect2 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:
@ -111,8 +111,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>
</refsect3>
<refsect3 id="linear-light">
</refsect2>
<refsect2 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 a CRT electron gun.
@ -126,8 +126,8 @@ $ vipsthumbnail fred.jpg --linear
<para>
The downside is that in linear mode, none of the very fast shrink-on-load tricks that <literal>vipsthumbnail</literal> normally uses are possible, since the shrinking done by the image libraries is done at encode time, and done in terms of CRT voltage, not light. This can make linear light thumbnailing of large images extremely slow.
</para>
</refsect3>
<refsect3 id="output-directory">
</refsect2>
<refsect2 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:
@ -156,8 +156,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>
</refsect3>
<refsect3 id="output-format-and-options">
</refsect2>
<refsect2 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: 
@ -231,8 +231,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>
</refsect3>
<refsect3 id="colour-management">
</refsect2>
<refsect2 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.
@ -259,8 +259,8 @@ $ ls -l tn_shark.jpg
<para>
You can also specify a fallback input profile to use if the image has no embedded one, but this is less useful.
</para>
</refsect3>
<refsect3 id="auto-rotate">
</refsect2>
<refsect2 id="auto-rotate">
<title>Auto-rotate</title>
<para>
Many JPEG files have a hint set in the header giving the image orientation. If you strip out the metadata, this hint will be lost, and the image will appear to be rotated.
@ -268,8 +268,8 @@ $ ls -l tn_shark.jpg
<para>
If you use the <literal>--rotate</literal> option, <literal>vipsthumbnail</literal> examines the image header and if there’s an orientation tag, applies and removes it.
</para>
</refsect3>
<refsect3 id="final-suggestion">
</refsect2>
<refsect2 id="final-suggestion">
<title>Final suggestion</title>
<para>
Putting all this together, I suggest this as a sensible set of options:
@ -281,7 +281,7 @@ $ vipsthumbnail fred.jpg \
--eprofile /usr/share/color/icc/sRGB.icc \
--rotate
</programlisting>
</refsect3>
</refsect2>
</refentry>