Search results

Thanks for the suggestions! It is .jxl, the encoder is called cjxl, the decoder is djxl, and the media type is image/jxl. I usually pronounce it jay-ex-ell, but it would be nice to pronounce it "yixel", since that rhymes with pixel. 1606252943 At version 0.2 we can do a delegate...

JPEG XL does support animation, but it's not a video codec: it does not have inter frames with motion estimation and all the complications and patent minefields that that brings. If you want well-compressed video, it's better to use a video codec. 1606252601 All the good stuff from FLIF went...

Hi everyone, long time no see :) JPEG XL reached version 0.1 recently. This is the "format release candidate" version; if all goes well we will soon proceed to version 0.2 which will be the "format release", i.e. bitstream stable enough to guarantee that encoded jxl files remain decodable. It...

About exiftool support: see https://github.com/FLIF-hub/FLIF/issues/307 :) (did one of you guys contact him or is this just a coincidence?) The issue with XMP when writing PNG has been fixed meanwhile (see https://github.com/FLIF-hub/FLIF/issues/308). There is no official standard for...

You can get rid of the SSE stuff by commenting out the #define USE_SIMD line in config.h. That should help to get it compiled on that Pentium 3 :) It was quite interesting! I put my paper and slides on the FLIF website, in case you're curious: http://flif.info/publications.html

I think the issue is in image/image.hpp, around line 238, where there is some code to align the pixel data on a 16-byte multiple. This code is probably buggy or something, but the bug was probably not discovered yet because on most platforms, the data is already aligned. OK. Should be fixed now...

Commenting out the #define USE_SIMD in config.h seems to solve the problem. I wonder if this is a compiler issue or a bug in the flif code.

OK, thanks for narrowing it down. So it's a problem in ColorBuckets. You can disable that transform during encoding with -B, and force it with -A.

Interesting. Could be an ARM vs x86 related bug...

No need to wait, if you start now, then if needed the libflif API can still be tweaked :)

Of course that can be done, but somebody still needs to do it :) Here's an overview of FLIF software support, which I try to keep up to date: http://flif.info/software.html There is a plugin for Qt4 / Qt5 (KDE), but none so far afaik for GTK (GNOME). It should in principle not be particularly...

FLIF is doing fine. Software support is indeed growing, e.g. ImageMagick supports it too now, and there's also a Windows codec for it. Too bad I didn't find time yet to add FLIF support to PIV -- to be honest, I'm not using my Pandora that often anymore since I stopped commuting to work (which...

Sounds good!

Animated FLIF uses one shared MANIAC tree (or rather a forest: it's one tree per color channel) for the entire animation. So if it learns correlations in one frame, it helps to compress other frames. It also has some intra-frame optimizations: FrameShape, a Lookback channel, duplicate frame...

Everything is looking great! About the color: +1 on making it darker. About the box: I voted for the smaller box. Better for shipping, but also: the box is not that important to me (it's not something I'm going to use after unpacking), but I'll probably still don't want to throw it away for...

1. Interesting idea to encode music as an image. You could use Red and Green to represent Left and Right (you can do up to 4 channels this way); make sure to use flif -Y to make sure it uses RGB and without YCoCg color transform. You would indeed need to align the music on a repetitive unit to...

Over 600 ! In other words, to stay with the Ancient Greek theme: the number of future Pyrates is now more than plus

That completely depends on what you are comparing it with. Are you comparing with desktops or full-size laptops? Sure, then the Pyra CPU is not very powerful. Not particularly weak either, just rather "meh" and the kind of thing you would expect to find in low-end machines. But that's not a...

I'm assuming that RAM refresh is only a tiny fraction of the power consumption. It should be insignificant for the usage time (i.e. when the screen is also powered, which will consumes orders of magnitude more power). It will have an influence on lid-closed standby time, but if that's too big of...

Oops, I should check the boards more frequently. I only saw this half an hour ago! Preordered! Pyra Preorder (Mobile Ed., EU-Vers., 4GB RAM)