Show newer

(272/300)

One nice thing that provides is the option to crop all layers at once. This can also be done with to crop the _output.mp4_.

Just follow this guide: [How can I crop a video with ffmpeg](video.stackexchange.com/a/4571)

Gimp or any other image editor app can be used to get a reference area for the crop area.

Hypothetically one combine step [265](qoto.org/@barefootstache/11231) and this one in one command.

Show thread

(271/300)

One would have hoped that one came full circle, though one came fully around with less data than before.

Let's start again from the beginning and use the method described in [265](qoto.org/@barefootstache/11231) without using . The only thing that is required is that the file names are in consecutive order. This can be done via

```
ls -1prt | grep -v "/$" | cat -n | while read n f; do mv -n "${f}" "$(printf "%06d" $n).${f#*.}"; done
```

Show thread

(270/300)

The issue with this approach is that when extracting the frames via one will only get the changes and the rest will be the alpha channel.

Thus when building the MP4 with won't look as expected.

One could go back in and merge each frame to the base layer (the first frame). Or just use the reference images.

Show thread

(269/300)

One option to handle the case is to follow this [guide](superuser.com/a/1688890). There are some modification that should be taken.

First extract the frames using

```
magick input.webp frames.png
```

Then use to build a MP4 video from the extracted frames

```
ffmpeg -r 1 -i frames-%0d.png -c:v libx264 output.mp4
```

Show thread

I'm working on adding a CLI toolchain to #Fedify to help with debugging. The first feature I implemented is the ActivityPub object lookup.

Here's a demo.

#fedidev #ActivityPub

(268/300)

Not only do have the animation halt in the though so do .

To overcome this issue, one can convert the specific file extension to a MP4.

For GIF one can run via this

```
ffmpeg -i input.gif output.mp4
```

Sadly, currently the same cannot be done with WEBP, since [decoding animated WEBP](trac.ffmpeg.org/ticket/4907) has not yet been implemented.

Show thread

(267/300)

also permits to export the animation as a . This will nullify the artefacts issue introduced by .

The only issue is if one wants to upload the result to the the animation won't be registered.

Show thread

(266/300)

The guide suggests to export the animation as a with a 1 frames per second.

This approach is fine if one is dealing with images that use less than 256 colors. Otherwise one will notice some compression artefacts.

Show thread

(265/300)

Now with the layers as frames one can use to merge them together to create a desired animation file.

```
ffmpeg -r 1 -i %06d.png -c:v libx264 out.mp4
```

This will create a MP4 with 1 frame per second. It is important the import naming `-i %06d.png` aligns with the export of layers modal.

To have a smooth looping experience, make sure to set the starting and ending frame be the same image. Just copy and past the start image and rename it so that it becomes the ending image.

Show thread

(264/300)

If one continues to use for sorting the images for the animation, then the [export-layers-plus tool](gimp-forum.net/attachment.php?) can ease the process of exporting all layers at once.

The user script can be saved in the _script-fu_ directory. The directory can be found by visiting `Edit > Preferences > Folders > Scripts`.

It is recommended to pad the layer number with zeroes. The suggested one is `%6i`, which will pad the number with zeroes until the number has a length of 6.

Script from the [Gimp forum](gimp-forum.net/Thread-exportin)

Show thread

(263/300)

The guide still has its place when dealing with images that are minorly misaligned. This is because on will need to adjust the images in such a manner that they overlap on top of each other.

This practice can be extended to the point that once a set of standardized images exist, then the ones that are misaligned can be filled and cropped to align with the standard.

Show thread

(262/300)

While looking back at the blog post on how to create a via (<bf5.eu/post/how-to-make-a-gif->) in regards to make animations for , I noticed that there are a couple of things that irk me that I have ignored previously.

These things include animation quality and process time.

(261/300)

The nice side effect is that the restriction puts me often in a state of . This is a blessing over a curse, since this opens the door for potential creativity.

These days one is constantly being bombarded with information to avoid being put in a state of boredom. Although one is constantly consuming content, many time one fails to scratch the curiosity itch.

Show thread

(260/300)

The situation that cost the most potential is during peak times.

These for me are before noon (12:00) and sometimes a second wave after 16:00. The 22:00 cut off is to remove any potential binging that would cut into .

Show thread

(259/300)

Over the last 60 days, I indirectly did a case study of one. I spent more than 240h .

One good thing that I added halfway through is the access to . These created the mirage that I was doing something semi-productive.

Sadly, in sessions that have the original intent of being just 10min, thus no need to put on a book, quickly becomes a multiple and thereby losing that time.

Show thread

(258/300)

The parent category has stronger restrictions.

1. is only permitted from 12:00 - 22:00.
2. During those times, the total gaming time permits only 2h.
3. There is the option to earn 5min extra time if one does 5min session.

These general restrictions were also put on other engineered binging technology like mainstream .

Show thread

(257/300)

has the option to have parent categories. This eases the behavior over multiple child categories.

If we continue from the example, they all have the same parent.

Show thread

(256/300)

When scouring the web for

> larger forearms than biceps

The two typical results are (unexpected) explicit training and genetics.

There is a more obvious one: optical illusion.

In this case the forearm is wider than the upper arm. It could be that the forearm is larger than the bicep though doesn't have to be, since both are measured as the circumference at the specific locations.

This illusion can be neutralized by either gaining weight via arm fat or via exercising the upper arm muscles.

Show older
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.