faster method for making movie in gnuplot - animation

I think we were using gnuplot for decades. But still there is no good way to get a good video output from gnuplot, am I right? What I did is made around 30,000 images (I had to make it with good quality too, to get video clarity), then used ffmpeg to make the video:
ffmpeg -f image2 -r 10.0 -i capture.%d.png -qscale 1 filename.mp4
But some time I get stuck in between or it takes too long time. We may always need a video output with high quality and low file size, why no one is attempting to do anything, or is there any other method to make video out put from gnuplot? I am really struggling to make high quality videos with gnuplot.

You can pipe the output of gnuplot directly to ffmpeg without storing the images on the hard drive. For that you need to tell ffmpeg what format and resolution it has to expect from the pipe, since it can not guess it alone from the extension etc. now. Here is an example:
gnuplot animation.plt | ffmpeg -f png_pipe -s:v 800x600 -i pipe: out.mp4
I used the code from here with some minor modifications.
animation.plt
#!/usr/bin/gnuplot
#
# Creating an animation gif of the Bessel function
# NOTE: this files creates multiple png images, the gif file is then created
# using GIMP
#
# AUTHOR: Hagen Wierstorf
reset
set terminal pngcairo size 800,600 enhanced font 'Verdana,10'
# color definitions
set palette rgb 3,9,9
unset key; unset colorbox; unset border; unset tics
set lmargin at screen 0.03
set bmargin at screen 0
set rmargin at screen 0.97
set tmargin at screen 1
set parametric
# Bessel function, which is moving in time
bessel(x,t) = besj0(x) * cos(2*pi*t)
# calculate the zeros for the bessel function (see Watson, "A Treatise on the
# Theory of Bessel Functions", 1966, page 505)
n = 6 # number of zeros
k = (n*pi-1.0/4*pi)
u_0 = k + 1/(8*k) - 31/(384*k)**3 + 3779/(15360*k)**5
set urange [0:u_0]
set vrange[0:1.5*pi]
set cbrange [-1:1]
set zrange[-1:1]
set isosamples 200,100
set pm3d depthorder
set view 40,200
# initializing values for the loop and start the loop
t = 0
end_time = 1
#system('mkdir -p animation')
load 'bessel.plt'
bessel.plt
# bessel loop
t = t + 0.02
#outfile = sprintf('animation/bessel%03.0f.png',50*t)
#set output outfile
splot u*sin(v),u*cos(v),bessel(u,t) w pm3d ls 1
if(t<end_time) reread;
Gives you a video which looks like this. (This is downscaled and transcoded gif just for demo purposes)
You can also play around with ffmpeg encoder parameters. here only default video encoder config is used.

Related

Image Conversion - RAW to png/raw for game (Pac The Man X)

So I have raw image and I am just curious If I can edit such image to save as RGB-32 Packed transparent interlaced raw and what program I could use, there is specification:
Format of RAW image
I have tried using photoshop but then game crashes. Is it even possible? I should get file without thumbnail. I also tried using gimp, free converters and Raw viewer but no luck. Any suggestions?
Edit:
Used photoshop (interleaved with transparency format), game starts but images are just bunch of pixels.
file that i try to prepare (221bits)
We are still not getting a handle on what output format you are really trying to achieve. Let's try generating a file from scratch, to see if we can get there.
So, let's just use simple commands that are available on a Mac and generate some test images from first principles. Start with exactly the same ghost.raw image you shared in your question. We will take the first 12 bytes as the header, and then generate a file full of red pixels and see if that works:
# Grab first 12 bytes from "ghost.raw" and start a new file "red.raw"
head -c 12 ghost.raw > red.raw
# Now generate 512x108 pixels, where red=ff, green=00, blue=01, alpha=fe and append to "red.raw"
perl -E 'say "ff0001fe" x (512*108)' | xxd -r -p >> red.raw
So you can try using red.raw in place of ghost.raw and tell me what happens.
Now try generating a blue file just the same:
# Grab first 12 bytes from "ghost.raw" and start a new file "blue.raw"
head -c 12 ghost.raw > blue.raw
# Now generate 512x108 pixels, where red=00, green=01, blue=ff, alpha=fe and append to "blue.raw"
perl -E 'say "0001fffe" x (512*108)' | xxd -r -p >> blue.raw
And then try blue.raw.
Original Answer
AFAIK, your image is actually 512 pixels wide by 108 pixels tall in RGBA8888 format with a 12-byte header at the start - making 12 + 4*(512 * 108) bytes.
You can convert it to PNG or JPEG with ImageMagick like this:
magick -size 512x108+12 -depth 8 RGBA:ghost.raw result.png
I still don't understand from your question or comments what format you actually want - so if you clarify that, I am hopeful we can get you answered.
Try using online converters. They help most of the time.\
A Website like these can possibly help:
https://www.freeconvert.com/raw-to-png
https://cloudconvert.com/raw-to-png
https://www.zamzar.com/convert/raw-to-png/
Some are specific websites which ask you for detail and some are straight forward conversions.

How to compress gif effectively to reduce size?

We use gifs for our blog extensively. We used to embed tenor nano gifs(90px height maintaining aspect ratio, used for GIF previews and shares on mobile) in it. Now we wanted to create our own gifs and are using the following command to convert mp4 to gif while maintaining the properties of tenor's nano gif. using ffmpeg version 4.1.4
But we observed a huge difference in size between the gif we created and the one created using tenor.
ffmpeg -i input.mp4 -filter_complex "[0:v]fps=10,scale=-1:90:flags=lanczos,split [a][b];[a] palettegen [p];[b][p] paletteuse" -y output.gif
[Original MP4] - 845KB
Tenor Nano gif - 42KB
ffmpeg gif - 106KB
We even tried changing dithering algorithm to further reduce size but it ended up adding noise and damaged the gif quality
paletteuse=dither=bayer:bayer_scale=5:diff_mode=rectangle
We tried tweaking colour quantization in gifsicle as well but it was of no use.
gifsicle --resize _x90 --colors 256 --color-method diversity --dither=ordered --resize-method sample input.gif > output.gif
What worked for me was specifying a lower frame rate (-r 10) for the output gif. Probably not what you want if you're after quality but if you're after quality file size may be the compromise.
Try this bat file. I wrote it for myself. I have Windows os.
It converts FFmpeg mp4 to gif
Create two packages Your_files and Result put the bat file next to the folders.
Put these folders and baht file next to ffmpeg.exe
Drag your files (file) to the Your_files folder
Run bat file
We take the finished files from the Result folder
color a
#echo off
set a="Your_files\*.mp4"
set b="Result\%%~na.gif"
set c=ffmpeg
set f=-filter_complex "[0:v] fps=10,scale=-1:-1:flags=full_chroma_int,split [a][b];[a] palettegen=max_colors=255:reserve_transparent=1:stats_mode=diff [p];[b][p] paletteuse=dither=none:bayer_scale=5:diff_mode=rectangle:new=1:alpha_threshold=128" -gifflags -offsetting
for %%a in (%a%) do (%c% -y -i "%%a" %f% %b%)
If it crashes, remove these lines: -gifflags -offsetting

Imagemagick Batch operation conditional on Filesize - How?

I'm running Imagemagick on a command line Ubuntu terminal in Windows 10 - using the built in facility in Windows 10 - the Ubuntu App.
I am a complete linux novice but have installed imagemagick in the above environment.
My task - Auto remove the black(ish) border and deskew the images of thousands of scanned 35mm slides.
I can successfully run commands such as
mogrify -fuzz 35% -deskew 80% -trim +repage *.tif
The problem is:-
The border is not crisply defined nor is completely black, hence the -fuzz. Some images are over-trimmed at a certain fuzz, while others are not trimmed enough.
So what I want to do is to have two passes at this, with different fuzz %, for these reasons:-
1st pass with a low Fuzz%. Many images will not be trimmed at all but I have found that the ones that are susceptible to over-trimming will trim Ok with low %
Since all the images start with an identical filesize, the ones that have trimmed Ok will have a lower filesize (note these are tifs not jpgs)
So what I need to do is set a file size condition for the second pass at higher fuzz% THAT IGNORES file sizes below a certain value and does not perform any operation.
In this way, with few errors, all the images will be trimmed correctly.
So the question
- How can I adjust the command line to have 2 passes and to ignore a lower file size on the second pass?
I have a horrible feeling the the answer will be a script. I have no idea how to construct or set up Ubuntu to run this so if so, please can you point me to help for that also!!
In ImageMagick, you could do something like the following:
Get the input filesize
Use convert to deskew and trim.
Then find the new file
Then compare the new to the old to compute the percentdifference to some percent threshold
If the percent difference is less than some threshold, then the processing did not trim enough
So reprocess with a higher fuzz value and write over the input; otherwise keep the first one only and do not write over the old one.
Unix syntax.
Choose two fuzz values
Choose a percent change threshold
Create a new empty directory to hold the output (results)
cd
cd desktop/Originals
fuzz1=20
fuzz2=40
threshpct=10
list=`ls`
for img in $list; do
filesize=`convert -ping $img -precision 16 -format "%b" info: | sed 's/[B]*$//'`
echo "filesize=$filesize"
convert $img -background black -deskew 40% -fuzz $fuzz1% ../results/$img
newfilesize=`convert -ping ../results/$img -precision 16 -format "%b" info: | sed 's/[B]*$//'`
test=`convert xc: -format "%[fx:100*($filesize-$newfilesize)/$filesize<$threshpct?1:0]" info:`
echo "newfilesize=$newfilesize; test=$test;"
[ $test -eq 1 ] && convert $img -background black -deskew 40% -fuzz $fuzz2% ../results/$img
done
The issue is that you need to be sure you set your TIFF compression for the output the same as for the input so that the file sizes are equivalent and presumably the new size is not larger than the old one as happens with JPG.
Note that the sed is used to remove the letter B (bytes) from the file size, so they can be compared as numerals and not strings. The -precision 16 forces "%b" to report as B and not KB or MB.

play stat -freq What does the output mean?

What does the output of play $file stat -freq mean?
I recently ran the command, here's a sample of the output:
$ play 44100Hz/3660/6517/3660-6517-0024.flac stat -freq
44100Hz/3660/6517/3660-6517-0024.flac:
File Size: 214k Bit Rate: 325k
Encoding: FLAC Info: Processed by SoX
Channels: 1 # 16-bit
Samplerate: 44100Hz
Replaygain: off
Duration: 00:00:05.28
In:0.00% 00:00:00.00 [00:00:05.28] Out:0 [ | ] Clip:0 0.000000 0.412632
10.766602 0.430416
21.533203 0.750785
32.299805 0.839694
43.066406 0.989763
53.833008 0.435572
64.599609 0.404773
75.366211 0.048392
86.132812 0.025195
96.899414 0.011314
...
In:3.52% 00:00:00.19 [00:00:05.09] Out:4.10k [ | ] Clip:0 0.000000 0.889006
10.766602 0.092675
21.533203 0.785106
32.299805 1.693663
43.066406 0.990839
53.833008 0.044969
64.599609 0.096066
75.366211 0.121797
86.132812 0.256809
96.899414 0.122486
107.666016 0.019195
...
How am I meant to understand this?
I hope that this is some Fourier transform and the above output represents a table like
Frequency | Level
But I don't know if that's the really case, or what level would be measured in were that the case.
And what do the lines starting with In:% mean? Ending with Clip:0 ....
Please can someone explain the output of this command to me.
From man page here:
The −freq option calculates the input’s power spectrum (4096 point DFT) instead of the statistics listed above. This should only be used
with a single channel audio file.
As you said, it is a Frequency / Level table.
So the last frequency is more or less the half of your sampling rate.
I tried it with a pure tone (generated in audacity) and it works quite well.
Be careful, if file length exceeds 4096 bytes per channel then you will see several sets of DFT, as the length of each DFT window is 4096. If so, then you will see several tables concatenated.
I don't have any '%'. Did you convert your audio file in mono as said in the documentation?
from man page here:
stat [-s scale] [-rms] [-freq] [-v] [-d]
Display time and frequency domain statistical information about the audio. Audio is passed unmodified through the SoX processing chain.
The information is output to the 'standard error' (stderr) stream and is calculated, where n is the duration of the audio in samples, c is the number of audio channels, r is the audio sample rate, and x k represents the PCM value (in the range -1 to +1 by default) of each successive sample in the audio, as follows:
...
The -freq option calculates the input's power spectrum (4096 point DFT) instead of the statistics listed above.
...

Determine bit depth of bmp file on os x

How can I determine the bit depth of a bmp file on Mac OS X? In particular, I want to check if a bmp file is a true 24 bit file, or if it is being saved as a greyscale (i.e. 8 bit) image. I have a black-and-white image which I think I have forced to be 24 bit (using convert -type TrueColor), but Imagemagick gives conflicting results:
> identify -verbose hiBW24.bmp
...
Type: Grayscale
Base type: Grayscale
Endianess: Undefined
Colorspace: Gray
> identify -debug coder hiBW24.bmp
...
Bits per pixel: 24
A number of other command-line utilities are no help, it seems:
> file hi.bmp
hi.bmp: data
> exiv2 hiBW24.bmp
File name : hiBW24.bmp
File size : 286338 Bytes
MIME type : image/x-ms-bmp
Image size : 200 x 477
hiBW24.bmp: No Exif data found in the file
> mediainfo -f hi.bmp
...[nothing useful]
If you want a commend-line utility try sips (do not forget to read the manpage with man sips). Example:
*terminal input*
sips -g all /Users/hg/Pictures/2012/03/14/QRCodeA.bmp
*output is:*
/Users/hg/Pictures/2012/03/14/QRCodeA.bmp
pixelWidth: 150
pixelHeight: 143
typeIdentifier: com.microsoft.bmp
format: bmp
formatOptions: default
dpiWidth: 96.000
dpiHeight: 96.000
samplesPerPixel: 3
bitsPerSample: 8
hasAlpha: no
space: RGB
I think the result contains the values you are after.
Another way is to open the image with the previewer preview.app and the open the info panel.
One of the most informative programs (but not easy to use) is exiftool by Phil Harvey http://www.sno.phy.queensu.ca/~phil/exiftool/ , which also works very well on MacOSX for a lot of file formats but maybe an overkill for your purpose.
I did this to investigate:
# create a black-to-white gradient and save as a BMP, then `identify` it to a file `unlim`
convert -size 256x256 gradient:black-white a.bmp
identify -verbose a.bmp > unlim
# create another black-to-white gradient but force 256 colours, then `identify` to a second file `256`
convert -size 256x256 gradient:black-white -colors 256 a.bmp
identify -verbose a.bmp > 256
# Now look at difference
opendiff unlim 256
And the difference is that the -colors 256 image has a palette in the header and has a Class:PseudoClass whereas the other has Class:Direct

Resources