Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
formát | datový tok [bpp] | kompresní poměr |
---|---|---|
PNG | 11.461131 | 2.094034 : 1 |
JPEG 2000 | 10.620645 | 2.259749 : 1 |
WebP | 10.619910 | 2.259906 : 1 |
H.265 | 12.460111 | 1.926146 : 1 |
FLIF | 9.978515 | 2.405167 : 1 |
JPEG XR | 11.575239 | 2.073391 : 1 |
AVIF | 12.039541 | 1.993431 : 1 |
FFV1 | 10.267328 | 2.337511 : 1 |
WebP 2 | 10.007292 | 2.398251 : 1 |
formát | datový tok [bpp] | kompresní poměr |
---|---|---|
PNG | 4.628656 | 5.185090 : 1 |
JPEG 2000 | 6.094012 | 3.938292 : 1 |
WebP | 4.294325 | 5.588771 : 1 |
H.265 | 7.158238 | 3.352780 : 1 |
FLIF | 3.774639 | 6.358223 : 1 |
JPEG XR | 8.097638 | 2.963827 : 1 |
AVIF | 8.198868 | 2.927233 : 1 |
FFV1 | 5.333731 | 4.499664 : 1 |
WebP 2 | 3.621495 | 6.627097 : 1 |
Tiskni Sdílej:
formát | datový tok [bpp] | kompresní poměr |
---|---|---|
bzip2 | 13.915411 | 1.724706 : 1 |
xz | 14.344152 | 1.673155 : 1 |
zstd | 15.619418 | 1.536548 : 1 |
brotli | 14.320850 | 1.675878 : 1 |
by bylo zajímavý vyzkoušet jak moc sou ty vobrázky v různejch formátech jakoby zranitelný proti náhodnýmu poškození nějakejch pár bitů taky :O :O voni si nejspíž vybrali formát podle tohodle taky :O ;D
to ale pak už nebude nějakej normální běžnej obrázkovej formát a bude to záviset na nějakým programu/kodecích ne?? :O :O
nejvíc nejlepší mi připadá mit různě poschovávanejch hrozně moc kopií toho samýho vobrázku a pak kdyžtak principem majority požkozenej vopravovat když se pozná chyba :O :O
optipng
), aby prošel kompletně všechny metody, tak to trvá. Ale kupodivu to zmenší velikost jen o 1% oproti "běžně" optimalizovanému png.
V rámci nějakého interního katalogu obrázků mám v toolchainu toto (python, Pillow):
from PIL import Image image.save(newfilename, 'png', optimize=True)Moc jsem nezkoumal co přesně "optimize=True" vlastně zapíná, protože vliv na rychlost (pocitově) to nemá skoro žádný, ale výsledné png je podle optipng (které trvá klidně i několik minut) cca o 1% větší než to nejlepší. Potom je docela zajímavá možnost použít nějaký skutečně bitmapový formát, třeba suckless farbfeld (který neřeší vůbec nic a je to jen pole pixelů) a použít nějakou obecnou kompresi (jak už zde byl uveden třeba bzip2 nebo zstd nebo cokoliv).
Jasným vítězem se stává formát FLIF.Mi přijde, že výsledek je až nezajímavě vyrovnaný. Nějakých zhruba +/- 10 % kolem běžného PNG. Shrnul bych to tak, že nejlepší je použít bezproblémové a rozšířené PNG, neboť alternativy jsou sice trochu lepší, ale ne o tolik, aby to stálo za námahu.
Zopflipng je ve všech případech nejlepší, ale taky trvá obludně dlouho.Já jsem zkoušel tebou doporučené parametry a jelo to hodinu. Potom jsem to stopnul. Nějakej 2MPx screenshot ze hry. To je asi dost nepoužitelné.
optipng -o7
trvá tak minuty. I obyčejný imagemagick convert -quality 100
odvede velmi dobrou práci v jednotkách sekund. (Optipng to zmenší tak o 2%, což už asi nemá smysl řešit.)
pngout má zásadní nevýhodu. Není v žádné distribuci. Ani v BSD portech. To by musel být fakt unikátní zázrak, aby si to lidi kompilovali.
tam na tý stránce nevidim nikde rgb24 :O :O
vidim jenom rgb8 a rgb16
nj to mi jako taky mohlo dojít :D
ale stejně chci svejch 72bpp :D :D ;D ;D
TIFF - historicky býval nejpouživačnější, hodně existujících archivů. Mám na CD/DVD z fotolabů hodně do TIFF naskovaných negativů.