commit 18240f34145e50a561d24f2c7e47729bc15d4c76
parent c10426d73875e8a3443d81cf1c95fcca84af7604
Author: Mattias Andrée <maandree@kth.se>
Date: Sun, 15 Jan 2017 14:27:27 +0100
Add project page for blind
Signed-off-by: Mattias Andrée <maandree@kth.se>
Diffstat:
2 files changed, 212 insertions(+), 0 deletions(-)
diff --git a/tools.suckless.org/blind/blind.svg b/tools.suckless.org/blind/blind.svg
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ id="svg4519"
+ version="1.1"
+ viewBox="0 0 210 297"
+ height="114"
+ width="246">
+ <metadata
+ id="metadata10">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <defs
+ id="defs4513" />
+ <circle
+ r="39.078949"
+ cy="148.5"
+ cx="-121.65789"
+ id="path4487"
+ style="opacity:1;fill:#231f20;fill-opacity:1;stroke:none;stroke-width:2.44972491;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <circle
+ style="opacity:1;fill:#231f20;fill-opacity:1;stroke:none;stroke-width:2.44972491;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="circle4489"
+ cx="-8.3289442"
+ cy="148.5"
+ r="39.078949" />
+ <circle
+ r="39.078949"
+ cy="148.5"
+ cx="105"
+ id="circle4491"
+ style="opacity:1;fill:#231f20;fill-opacity:1;stroke:none;stroke-width:2.44972491;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <circle
+ style="opacity:1;fill:#231f20;fill-opacity:1;stroke:none;stroke-width:2.44972491;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="circle4493"
+ cx="218.32896"
+ cy="148.5"
+ r="39.078949" />
+ <circle
+ r="39.078949"
+ cy="148.5"
+ cx="331.65787"
+ id="circle4495"
+ style="opacity:1;fill:#231f20;fill-opacity:1;stroke:none;stroke-width:2.44972491;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+</svg>
diff --git a/tools.suckless.org/blind/index.md b/tools.suckless.org/blind/index.md
@@ -0,0 +1,156 @@
+
+
+blind is a collection of command line video editing utilities.
+
+Video format
+------------
+
+blind uses a raw video format with a simple container. A
+file begins with an plain-text line, containing the
+number of frames, the width, the height, and the pixel
+format, all separated by a single regular blank space,
+without and leading or tailing white space. After this
+line, which ends with an LF, there is a NUL-byte
+followed by the 4 characters “uivf” (unportable, interim
+video format). This head is followed by the video
+frame-by-frame with row-major frames. Pixels ares
+independently encoded, and are encoded unscaled CIE XYZ
+with non-premultiplied alpha and without any
+transfer-function, with values stored in native `double`s.
+This colour model and space is the only option at the
+moment, but the container format is designed so this can
+be changed in the future.
+
+Unscaled CIE XYZ was choosen because it gives good
+performance for most operations. Most videos use Y'UV;
+this format has good performance for converting to sRGB
+and is has good subsampling quality, but it is not a
+good for editing. `double`s are used instead of `float`s
+because has higher precision: 52 instead of 23 fraction
+bits. However, `float`s have
+[much better](http://www.tomshardware.com/reviews/geforce-gtx-titan-gk110-review,3438-3.html)
+performance than `double`, so support for in may be
+added in the future.
+
+FAQ
+---
+
+### Doesn't raw video takes up a lot of space?
+
+Yes it does, a 4-channel pixel encoded with `double`
+takes 32 bytes. A 1280-by-720 frame with this pixel format
+takes 29.4912 MB (SI), which means you can only fit almost
+3391 frames in 100 GB, which is about 113 seconds or 1:53
+minutes with a framerate of 30 fps. Therefore, you
+probably do not want to store anything in this format
+unless you know you have room for it, or if it is very
+small segment of your video, which unfortunely becomes a
+bit of a problem when reversing a video. However, when
+possible, feed the resulting video directly to
+`blind-to-video` to convert it into a compressed,
+lossless video format, if the video is not too large, you
+can choose to compress it with bzip2 instead.
+
+### Does it support farbfeld?
+
+Of course. If you want to use farbfeld, you can use
+the `-f` flag for `blind-to-image` and `blind-from-image`,
+this will cause the programs to convert directly to
+or from farbfeld without using `convert(1)`.
+
+### For what kind of video editing is blind designed?
+
+It is designed for composing new videos. It it not
+designed for making small changes as this can probably
+be done faster with a graphical video editor or with
+ffmpeg which would also be much faster.
+
+### Creating videos without graphics, are you insane?
+
+Yes, but see the rationale below!
+
+### Why doesn't blind use sRGB?
+
+If I tell you I use CIE XYZ, you will only have two
+questions: “how are values stored?” and “is Y scaled
+to [0, 100] or [0, 1]”. When I tell you I use sRGB
+your have more questions: “do you support out-of-gamut
+colours?”, “how are values stored?”, “which scale
+do you use?”, and “is the transfer-function applied?”
+
+CIE XYZ also has the advantage of having the brightness
+encoded in one of its parameters, Y, which means that
+operations that want to deal with brightness only or
+chroma only does not need to do any conversions.
+
+### Why does blind use CIE XYZ instead of CIE L*a*b*?
+
+Because CIE L*a*b* is not linear, meaning that it
+requires unnecessary calculations when working with
+the colours.
+
+### Why does blind use CIE XYZ instead of Y'UV or YUV?
+
+Because Y'UV, which most videos use (for legacy
+reasons, namely that of black-and-white television)
+is not linear it has the same disadvantages as
+CIE L*a*b*. Y'UV does not have its transfer-function
+applied directly to it's parameters, instead it is a
+linear transformation if the sRGB with its
+transfer-function applied. This means that no performance
+is gained during convertion to or from cooked video
+formates by using YUV. CIE XYZ also has the advantage
+that it is well-known and has a one-step conversion
+to almost all colour models. It also have the advantages
+that it's parameters are named X, Y, Z, which makes it
+very easy to choose parameter when storing points
+instead of colours in a video.
+
+### Doesn't blind have any audio support?
+
+No, it is not clear that there is actually a need for
+this. There are good tools for editing audio, and
+ffmpeg can be used be used to extract the audio streams
+from a video or add it to a video.
+
+Rationale
+---------
+
+* It's source control friendly and it's easy for a user to
+ resolve merge conflicts and identify changes.
+
+* Rendering can take a very long time. With this approach,
+ the user can use Make to only rerender parts that have
+ been changes.
+
+* No room for buggy GUI:s, which currently is a problem on
+ the large video editors for Linux.
+
+* Less chance that the user makes a change by mistake
+ without noticing it, such as moving a clip in the editor
+ by mistake instead of for example resizing.
+
+* Even old crappy computers can be used for large projects.
+
+* Very easy to utilise command line image editors for modify
+ frames, or to add your own tools for custom effects.
+
+Development
+-----------
+
+You can browse its [source code repository](http://git.suckless.org/blind)
+or get a copy using git with the following command:
+
+ git clone http://git.suckless.org/blind
+
+Dependencies
+------------
+
+* ffmpeg - for converting from or to other video formats.
+
+* imagemagick - for converting regular images to frames.
+
+Author
+------
+
+* Mattias Andrée (maandree@kth.se)
