qt-avif-image-plugin
qt-avif-image-plugin copied to clipboard
novomesk
Upstream plugin to Qt
Hello, please upstream your work to Qt, so all Qt users can profit from it. If you've got any questions about the process, build system, etc., feel free to ask. :)
You basically "just" need to insert your plugin here along with the others: https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/imageformats
When I asked in the past what to do so it could be included, I received following instructions: https://wiki.qt.io/Qt_Contribution_Guidelines Do you have experiences in contributing to Qt?
Do you have experiences in contributing to Qt?
Yes, at least some, I submitted a few small patches. You can ask me if there's something you don't understand in the Qt wiki.
- Have you got a Qt account for https://codereview.qt-project.org and https://bugreports.qt.io already?
- Have you got a local checkout of
git://code.qt.io/qt/qt5.gitand have you managed it to compile qtbase?
(Just FYI: I actually first thought about writing such a plugin, but then found yours. Unfortunately I probably can't submit your code, because of Qt's CLA. And I guess Qt's probably also happy to get a new contributor :))
I would not hurry now. I use libavif from git now, let's wait for next release. libavif is not present in many Linux distributions, Qt project would need to build it locally (probably together with libaom). It is easy to do it on my own computer but I am not expert in preparing sophisticated Qt .pro files. This is area where I need help. I have still few things on my TODO list for this plugin. I think I don't have those accounts yet, building Qt should be no problem.
I use libavif from git now, let's wait for next release.
OK, I see.
libavif is not present in many Linux distributions, Qt project would need to build it locally (probably together with libaom). It is easy to do it on my own computer but I am not expert in preparing sophisticated Qt .pro files. This is area where I need help.
(Unfortunately or in this case fortunately) Qt requires all dependencies to be bundled with Qt. There are options to use the system wide installation, but there must always be a fallback.
Qt currently has two build systems: CMake and QMake. The QMake build system will be removed soon(tm) (it will still be supported, but you won't be able to build Qt using it). Currently the .pro files are automatically converted to cmake files. Writing the QMake files isn't that hard as long as the dependencies support pkg-config (which they probably do). I could help you with this part, but you can also just wait for qmake being dropped.
Oh, and what I said in the issue description isn't completely correct: Only the gif, png and ico plugins belong to QtGui, all other/new plugins go into qtimageformats.
Qt currently has two build systems: CMake and QMake. The QMake build system will be removed soon(tm) (it will still be supported, but you won't be able to build Qt using it).
sort of an off-topic, do you happen to know when this might happen in a release tag? I personally am compiling qt in windows on msys2 and using qmake is honestly a pain because of weird makefile generation and other stuff like compile time being long and not being able to enable ccache without a patch for qmake. I do see CMake stuff inside the dev branch on qtbase, but not in any of the tags and I'm not sure how fully-featured the CMakeLists are yet
@1480c1 Qt 6.0 will have full cmake support that you can (or maybe even have to) use. Building Qt with cmake on the dev branch already works well for most use-cases. There won't be cmake support for any of the 5.x releases.
Nice, thanks for the information.
Maybe I might retry a compilation using cmake sometime soon
I looked at the way Qt builds third party libraries: https://github.com/qt/qtimageformats/tree/dev/src/3rdparty
AVIF has longer list of dependencies unfortunately.
First you need nasm/yasm to to build accelerated code in libaom. When libaom is build, you can start building libavif. When libavif is done, you can build my plug-in.
In order to conveniently fit existing Qt build script it is possible to make a bundle of libaom (without assembler) + libavif + my qt-avif-image-plugin, it would work on all platforms. Unfortunately saving AVIF with unoptimized libaom configuration is very slow especially for large images. It is better to build libaom in official way, but the chain of dependencies must be done in multiple steps I believe. I know what has to be done but I don't know how to integrate those steps into Qt build script.
I'm not 100%-sure whether this is an option, but since this is a plugin it's probably ok if it's not always available. This means we could require an external libaom and libavif build. This would mean that the plugin maybe isn't shipped on all platforms, but anyone who really needs it can additionally build it.
It Qt scares you, i'm going to say that we are KDE are a friendly bunch and i think having this in kimageformats would be a good reasonable first step to get it distributed to a wider audience :)
@tsdgeos You are right, I feel bit scared to go to Qt directly now.
Adding to kdeimageformats is a good idea, it can be done easily. libavif (the library I use) is now available on many platforms, see: https://repology.org/project/libavif/versions
However, there is one complication. libavif is progressing rapidly and there were many breaking changes this year. Probably there will be more breaking changes in the future, so at some point the old plug-in code will stop to compile with newly released libavif. I am able to quickly adapt to those changes but I don’t know if KDE has such short release cycle. Making a local build of compatible libavif and link statically with the plugin-in would mitigate the problem.
@tsdgeos Please try to look at https://github.com/novomesk/kimageformats and tell me what do you suggest to do next.
Please open a Merge Request against https://invent.kde.org/frameworks/kimageformats and let's talk there :)
Shout if you have questiona about how to use gitlab
@eclipseo @jbeich FYI, This plug-in code is included in KImageFormats
It won't be necessary to install qt-avif-image-plugin in the future, when the plug-in will be installed via future versions of kimageformats.
@eclipseo @jbeich FYI, This plug-in code is included in KImageFormats
It won't be necessary to install qt-avif-image-plugin in the future, when the plug-in will be installed via future versions of kimageformats.
Noted, i patched my local KImageFormatsand it works well. However animated AVIF are not playing unlike your JXL plugin. Is there something specific to code to support animated AVIF? The animations in AVIF are well compressed over its JXL equivalent.
@eclipseo @jbeich FYI, This plug-in code is included in KImageFormats It won't be necessary to install qt-avif-image-plugin in the future, when the plug-in will be installed via future versions of kimageformats.
Noted, i patched my local KImageFormatsand it works well. However animated AVIF are not playing unlike your JXL plugin. Is there something specific to code to support animated AVIF? The animations in AVIF are well compressed over its JXL equivalent.
Disregard, it's the encoding from APNG which fails.
@novomesk Apologies if I'm missing something obvious, but should Gwenview 20.12.2 support AVIF out of the box when KImageFormats 5.79.0 is installed? I still get 'Gwenview cannot display documents of type image/avif'.
@Quppa kimageformats can be built with or without AVIF support. For example when libavif is missing then kimg_avif.so is not built.
Check if you have kimg_avif.so in /usr/lib/qt5/plugins/imageformats (or /usr/lib/qt/plugins/imageformats/ or /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats)
If you don't have kimg_avif.so, then you can install this qt-avif-image-plugin (you will have libqavif.so).
I just don't recommend having both libqavif.so and kimg_avif.so at the same time.
Thanks - I kind of forgot about this and at some point AVIF support started working (currently running Gwenview 20.12.3 and KImageFormats 5.80.0).