Note: Output size is 10x10 for demonstration, since blending is consistently 2 pixels. I then scaled the output to 100x100 for easier web viewing.
Output vs Expected output:
melt \
-video-track color:0x00ff00ff length=0 \
-video-track color:0xff0000ff length=0 \
-transition composite geometry="0=50%/0%:100%x100%" distort=1 \
-consumer avformat:out.png vcodec=png pix_fmt=rgba width=10 height=10
I've tried adjusting all composite parameters with no luck. I expected distort to not allow the soft blending, but still occurs. Also adjusted softness, although it's defaulted to 0, and it requires the luma parameter.
Been scratching my head about this one for years, might just be a bug possibly?
The composite transition only works in yuv422 colorspace. But your output is RGBA. So a sample format conversion will occur from 4:2:2 to 4:4:4. The new samples are interpolated from adjacent samples - which causes the chroma bleeding.
There have been recent improvements in this conversion code which may reduce the chroma bleeding if you use a newer version of melt:
https://github.com/mltframework/mlt/commit/557852970cd661e471f14a358ec96aed25383020#diff-2e495e9ae505e2a8c1d04e9868f4cf06
Alternately, the affine transition operates in RGB. So you might avoid the bleeding if affine can work for you:
https://www.mltframework.org/plugins/TransitionAffine/
Related
I know that ncurses supports 16-bit colors with the init_pair function and friends. But is it possible to display characters in full RGB color (aka True Color)?
The ncurses FAQ Why only 16 (or 256) colors? goes into some detail, giving the history of this feature, pointing out that the proper term is direct color (since that is based on a standard, while true color is in other places said to be a special case of direct color). Likewise, the xterm FAQ Can I set a color by its number? provides corresponding detail on the history of this feature in xterm.
ncurses 6.1 (January 2018) introduced support for direct color, as illustrated in a recap of the ncurses versus slang history. That includes an example program picsmap which uses the RGB extension (documented in user_caps(5)).
Because the number of colors in 24-bit RGB is larger than the range of numbers supported in the original (signed!) 16-bit numbers (see term(5)), it was necessary to provide for larger numbers. ncurses 6.1 does this with minimal change to existing applications by adding to the opaque TERMINAL structure, and adding functions which can manipulate the extended numbers. It was not necessary to change the ABI (currently 6 since August 2015), because none of the documented features changed their binary interface.
To use the RGB feature in ncurses it is necessary to have the proper terminal description. xterm-direct is used for xterm. This example sets the RGB flag and overrides the color features (but reserves the first 8 ANSI colors, making it a workable hybrid):
xterm+direct|xterm with direct-color indexing,
RGB,
colors#0x1000000, pairs#0x10000, CO#8,
initc#, op=\E[39;49m,
setab=\E[%?%p1%{8}%<%t4%p1%d%e48\:2\:\:%p1%{65536}%/%d\:%p1
%{256}%/%{255}%&%d\:%p1%{255}%&%d%;m,
setaf=\E[%?%p1%{8}%<%t3%p1%d%e38\:2\:\:%p1%{65536}%/%d\:%p1
%{256}%/%{255}%&%d\:%p1%{255}%&%d%;m,
setb#, setf#,
Other terminals have their corresponding flavors. Because the feature is documented, with examples, it is possible for others to customize terminal descriptions as needed.
picsmap is one of the test-programs for ncurses, which is available separately as "ncurses-examples". Tutorials are off-topic; the source-code is readily available.
“True Color” is a bit of a misnomer—it does not exist.
Ncurses lets you redefine the values of the standard 16 colors, but does not support arbitrary RBG colors at arbitrary positions. Fortunately, many terminals do support 8-bit RGB (sometimes called “true color”) if you wish to do it yourself—to be clear, this means not using ncurses.
The sequences are:
ESC[ 38;2;⟨r⟩;⟨g⟩;⟨b⟩ m: Select RGB foreground color
ESC[ 48;2;⟨r⟩;⟨g⟩;⟨b⟩ m: Select RGB background color
(From ANSI Escape Code)
Here, “ESC” is just the character ‘\x1b’ and you replace r, g, and b with values from 0-255. Something like this:
printf("\x1b[38;2;%d,%d,%dm", r, g, b);
This does not work on all terminals but there are plenty that do support it.
Why Not Ncurses?
Why doesn’t Ncurses support this? It turns out that Ncurses is not just a library for styling text and placing it at different locations on the terminal, but it also tries to be clever and minimize the amount of data transmitted over stdout when the on-screen text changes. Ncurses does this by keeping its own text buffer internally, and transmitting deltas over stdout.
This is a really nice feature to have if you’re running over a 14.4 kbit/s modem or a slow serial connection back in 1993, back when Ncurses was originally made. However, Ncurses has made an implementation tradeoff of not supporting additional colors.
I have to calculate the flight path of a projectile and draw the result in a bitmap file. So far I'm pretty clueless how to do that.
Would it be a good idea to safe the values of the flight path in a struct and transfer it to the bitmap file?
Do you have any other suggestions how it could be done in a better way?
The simplest way to produce an image file without much hassle with only standard C library tools is most likely writing a bmp file. For start, check the Wikipedia article on this file format, it gives a quite complete description of it.
If you don't want to go too deep in that, save for example a 640x480 or so empty 24 bit ("truecolor") .bmp image, and rip out it's header for your use. Depending on the program you use to save your image, you might end up with varying header size, however since the data is not compressed, it is fairly easy isolate the header. For a 640x480 image the data will be exactly 921600 bytes long, anything preceding it is the header.
From here the colors are (usually) in RGB order, bottom to top row, left to right. Experimenting a little should give you the proper results.
If you only have the standard C libraries to work with, it is unlikely there is anything much simpler to implement. Of course this case you will have to write a pixel matrix (so no much assistance for solving the actual problem you want to image), but that's true for any image format (maybe except if you rather aim for creating an SVG for a twist, it is neither too hard, just XML).
Consider the following file:
-rw-r--r-- 1 user user 470886479 2009-12-15 08:26 the_known_universe.png
How would you scale the image down to a reasonable resolution, using no more than 4GB of RAM?
For example:
$ convert -scale 7666x3833 the_known_universe.png
What C library would handle it?
Thank you!
I believe libpng has a stream interface. I think this can be used to read parts of the image at a time; depending on the image file you might be able to get the lines in order. You could then shrink each line (e.g. for 50% shrinking, shrink the line horizontally and discard every second line) and write to an output file.
Using libpng in C can take a fair amount of code, but the documentation guides you through it pretty well.
http://www.libpng.org/pub/png/libpng-1.2.5-manual.html#section-3.8
You could try making a 64 bit build of ImageMagick or seeing if there is one. My colleague wrote a blog with a super-simple png decoder (assumes you have zlib or equivalent) so you can kind of see the code you'd need to roll your own.
http://www.atalasoft.com/cs/blogs/stevehawley/archive/2010/02/23/libpng-you-re-doing-it-wrong.aspx
You would need to do the resample as you're reading it in.
I used cximage a few years ago. I think the latest version is at
http://www.xdp.it/cximage.htm
after moving off of CodeProject.
Edit: sorry, it's C++ not C.
You could use an image processing library that is intended to do complex operations on large (and small) images. One example is the IM imaging toolkit. It links well with C (but is implemented at least partly in C++) and has a good binding to Lua. From the Lua binding it should be easy to experiment.
libvips is comfortable with huge images. It's a streaming image processing library, so it can read from the source, process, and write to the destination simultaneously and in parallel. It's typically 3x to 5x faster than imagemagick and needs very little memory.
For example, with the largest PNG I have on my laptop (1.8gb), I can downsize 10x with:
$ vipsheader huge.png
huge.png: 72000x72000 uchar, 3 bands, srgb, pngload
$ ls -l huge.png
-rw-r--r-- 1 john john 1785845477 Feb 19 09:39 huge.png
$ time vips resize huge.png x.png 0.1
real 1m35.279s
user 1m49.178s
sys 0m1.208s
peak RES 230mb
Not fast, but not too shabby either. PNG is rather a slow format, it would be much quicker with TIFF.
libvips is installable by most package managers (eg. homebrew on macOS, apt on Debian), there's a Windows binary, and it's free (LGPL). As well as the command-line, there are bindings for C, C++, Python, Ruby, Lua, node, PHP, and others.
Have you considered exploring pyramid based images? Imagine a pyramid where the image is divided up in multiple layers, each layer with a different resolution. Each layer is split up into tiles.
This way you can display a zoomed out version of the image, and also a zoomed in partial view of the image, without having to re-scale.
See the Wikipedia entry.
One of the original formats was FlashPix, which I wrote a renderer for.
I've also created a new format of a pyramid converter and renderer, which was used for a medical application. An actual scanner would produce 90GB+ scans of a slice of an organ for cancer research.
The algorithm of the converter was actually pretty tricky to get efficient, to produce the pyramid images efficienty. Believe it or not, it was actually Java based, and it performed much better than you'd think. It used multithreading. Benchmarking showed it was unlikely that a C version would do a whole lot better. This was 6ish years ago. The original renderer I did over 10 years ago.
You don't hear anything about pyramid based images anymore these days. But it's really the only efficient way to produce scaled images on demand without having to generate cached scaled versions.
Jpeg2000 may or may not have an optional pyramid feature as well.
I recall that ImageMagick's supporter formats and conversions perhaps, include FlashPix.
Googling for "image pyramid" reveals some interesting results. Bring back some memories ;-)
If you can move it to a 64-bit OS you can open it as a memory mapped file or equivalent and use pretty much any library you want. It won't be fast, and may need the increase of the page/swap file (depending on the OS and what else you want to do with it) but in return you won't be limited to streaming libraries so you'll be able to do more operation before going into resolution reduction or slicing.
I regularly run into C-codes without folding. It is irritating to read them if there is no folding, particularly with long files. How can I fold them?
To fold according to syntax
:set foldmethod=syntax
If you want to do it manually on the bits you want to fold away
:set foldmethod=manual
then create new folds by selecting / moving and pressing zf
e.g.
shift-v j j zf
(ignoring the spaces)
Edit: Also see the comments of this answer for indent and marker foldmethods.
I think you may have mixed the terminology. Do you need "wrapping" or "folding". Wrapping is the one where lines that wouldn't usually fit on screen due to their length, are wrapped, i.e. shown on several consecutive lines on screen (actually, it is one line, in several lines - hard to explain, best to see in practice).
In vim wrapping is set by
:set wrap
to turn it on, and
:set textwidth=80
to determine where vim should wrap the text (80 characters is usually a nice measure).
Folding on the other hand is a completely different matter. It is the one where vim folds several lines of code (for example, a function) into one line of code. It is useful for increasing readability of code. Vim has several folding methods, you can see all of them if you
:help folding
What you are looking for, I think would be, syntax folding, but I could be wrong. I recommend reading the help page, it is not long, and very useful.
Actually, there is another very straight forward and effective way, which is using foldmethod = marker and set foldmarker to be {,}. Then the fold result would looks like:
all of the functions fold-ed. Basically, it looks like the outline in IDE. (and you can also set foldlevel=1or more, if you do not want to fold everything at the beginning)
this is what a normal function looks like when you open it with level-1 via zo.
In addition, to do folding by syntax needs a bit of extra work, and here is a good tutorial about it. But I think fold by marker={,} is quite enough, and most importantly, it's simple and neat.
I've rolled up a fold plugin for C and C++. It goes beyond what is done with syntax folding (may be it could be improved, I don't know), and leaves less noisy and not really useful things unfolded, compared to indentation and marker based folding.
The caveat: in order to have decent reaction times, I had to make some simplifications, and sometimes the result is quite messed-up (we have to type zx to fix it).
Here is a little screencast to see how the plugin folds a correctly balanced C++ source code, which is not currently being modified :(
In vi (as opposed to vim) the answer was:
:set wm=1
This sets the wrap margin to one character before the end of the line. This isn't the world's best specification with variable sized windows (it made sense with green screens when it was hard to change the size).
That means there is also an alternative way to do it in vim:
:set textwidth=30
See: VimDoc User Manual Section 25.1
The you probably want the setting
:set foldmethod=syntax
But don't put that in manually! Thats missing out on one of Vims biggest features which is having custom settings for hundreds of file types already builtin. To get that, add this to your ~/.vimrc
filetype plugin on
filetype indent on
filetype detection is mostly based on extension, in this case *.c files. See :help :filetype for more info. You can also customize these filetype based settings.
I'm trying to render frames coming from an mkv h264 file in silverlight 3 by using the MediaStreamSource.
Parsing the mkv file is fine, but I'm struggling with the expected values for CodecPrivateData in SL, which has to be a string, while the PrivateData info from mkv is a binary element.
Also, I'm not sure about in which form the frames should be given to SL (ie, the way they are stored in mkv / mp4, or transcoded as NALU)
Would anyone have any info on this?
After similar problems of my own and much head-scratching, I am able to answer this question.
In ReportOpenMediaCompleted(), when setting up your video stream description, you can ignore the CodecPrivateData attribute string, despite what the documentation says. It's not required. (assuming your stream of NAL units includes SPS and PPS units)
You should send one NAL unit back to the MediaElement for each GetSampleAsync() request.
This includes non-picture NAL units, e.g. SPS / PPS units.
When you send your NAL units, ensure there are 3-byte start codes (0x00 0x00 0x01) at the beginning of each one. (This is similar to 'Annex B' format, but not quite the same thing)
In ReportGetSampleCompleted(), set the value of 'Offset' equal to the beginning of the NAL start code, not the actual data. (in most cases this will be zero, assuming you use a fresh stream per NAL unit)
I have blogged a little about the experience here and hope to blog more.
According to the documentation the Codec private data should be set to 00000001 + sps + 00000001 + pps. However the documentation is wrong the value of CodecPrivateData seems to be completely ignored. Instead you need to pass the SPS and PPS NALS (with an annex b header of course) as the first and second result of GetSampleAsync.
For regular media samples normal 4 byte annex b headers headers work just fine
The CodecPrivateData is the contents of the 'avcC' atom which is a child of the 'stsd' atom in an MP4 file. You have to convert the binary data to a string. It will look something like this: "014D401FFFE10017674D401F925402802DD0800000030080000018478C195001000468EE32C8"
You also have to replace the mkv/mp4 lengths to NALU. I've written a little about this (to get Smooth Streaming to work for H.264 files).
Regards,
See: Smooth Streaming H264