They were already disabled when building with Qt >= 5.3 in commit
3d45b270ea8341d1516d5863cc49884c2744f2f2 because Qt has better plugins
for those image formats. Now that we depend on Qt 5.3 we can remove
them.
REVIEW: 124636
image formats are loaded via qimage/qimagereader and friends, the user/developer does not choose which ones will be used so giving him a warning about sequential devices not being supported is not going to help anyone, only spam their shell/logs.
REVIEW: 123156
Acked by David Edmundson
By using the same strategy as the SoftImage PIC handler (and sharing
some code with it), we should avoid reading the image data incorrectly
on big-endian architectures.
REVIEW: 122650
BUG: 337918
QtImageFormats 5.3 comes with DDS and JPEG-2000 plugins that support
more options and are generally better than our plugins. The only
advantage our plugins offer is that the Qt DDS plugin does not work on
sequential devices, while ours does. This is outweighed by other
improvements, though, such as supporting more variants.
REVIEW: 119590
Frameworks have a convention of naming uninstalled headers in src/ with
a _p at the end of the name, to make it clear they are not part of the
API. None of the headers in KImageFormats are installed, so it is not
really necessary to follow this convention, but we follow it anyway for
the benefit of both humans and tools (like kapidox).
The "+ 1" was causing an unsigned value to be cast to a signed value,
which was then compared with an unsigned value, causing the warning.
Making the constant unsigned fixes this.
It now uses QDataStream to deal with endianness. It also supports
several QImageIOHandler options.
This comes with a more comprehensive test suite than the old code. Note
that the old test suite was incorrect as the old code wrote the floats
in the header out incorrectly (although no-one noticed because no
software seems to care about those values).
All the test PIC files in the test suite appear correct according to the
specification (by inspection with Okteta). Unfortunately, there is a
lack of other freely-available software that reads and writes PIC files
(the main application that uses them is proprietary), and so this is the
best I can do.
REVIEW: 117944
This prevents a clash with kde-runtime 4, and is a better naming scheme
anyway (to prevent accidental clashes with mime packages from other
software).
REVIEW: 115913
This both excludes the autotests and tests subdirs if the user sets
BUILD_TESTING off, and makes sure we do not run tests for formats that
were not built due to dependencies not being found.
REVIEW: 115504
This includes the detection magic and an alias for image/webp. It
should be in shared-mime-info 1.3.
Proposed by Jerome Leclanche <adys.wh@gmail.com>.
REVIEW: 115355
The plugin export mechanism has been patched up (including the addition
of the JSON file), and the FindWebP.cmake file is new.
Writing is currently disabled, as it produces broken images.
Autotests are generated using the cwebp and dwebp utilities distributed
with the libwebp reference library.
REVIEW: 115355
It appears to be some internal format of xview, although I cannot find
any mention of such a thing on the internet. There does not appear to
be any sort of mime type to associate with this file format, either.
Therefore, I think it is reasonable to declare it obsolete.
REVIEW: 115768
src/imageformats/CMakeLists.txt is now much clearer and more consistent.
Also, removed an unnecessary/unimplemented method from exr.cpp.
REVIEW: 115120
