[Development] qdds image format

[Иван Комиссаров]

2018-04-17 11:02 GMT+03:00 Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>:

> On 17/04/18 08:09, Иван Комиссаров wrote:
>
>> Looking at the email archives: it was fuzzed through AFL. I don't have
>>> the test images still around, but in my experience a simple multi-image
>>> file was enough to trigger a crash. (I used to see this in Creator, when
>>> accidentally opening a DDS in its builtin image preview).
>>>
>> What is AFP?
>>
>
> American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/
>
> But again, why having such an image loader in Qt? It's not going to be
>>> useful in 99.9% of the use cases where you use a DDS file.
>>>
>> Well, opening DDS file in Qt Creator is that «0.01%» usecase, but it’s
>> quite convenient to do such thing. In case it doesn’t crash, though:(
>>
>
> I wasn't trying to open it to do anything meaningful, it was because the
> DDS was in a resource file and Creator tries to build an icon for it or
> tries to visualize it when clicked. This triggered the crash in the DDS
> imageformat plugin.
>

Yeah, that's bad


>
> Or you’re developing a game and you need a map/level qwidget-based editor
>> - it definitely should be able to open (and save) such textures. > Or
>> you’re writing an archiver for a game with a file preview.
>>
>
> The problem I'm talking about is the API, not the feature itself: to
> properly handle DDS files you can't use QImage and QImageReader. So why
> having such support in a qtimageformat?
>
> We're talking about a format meant to store textures: how do you retrieve
> a mipmap chain using QImageReader? How do you retrieve a specific array
> level? How do you retrieve a specific cubemap face? How do you handle the
> formats that DDS can store and QImage can't represent?
>
> If the idea is to use a more specialized API for DDS files, I'm all for it
> -- as I said before, let's add it to QtGui, and work with other texture
> containers (KTX, etc.). My concern is about using QImage and its APIs for
> this.
>

Well, i'm fully aware of the limitations of the QImageReader/Writer API and
i one of the reasons i wrote DDS plugin is to see them *on practice*. I'm
not sure if the API should be completely rewritten to support textures or
slightly modified, but the truth is that current API doesn't even allow to
implement writing plain-array files like GIF's *sigh*.
I like the idea moving DDS suppport to a separate lib (and QImageReader can
use that lib for preview purposes in QtCreator/QFileSystemModel within it's
limited capabilities).
About your concerns about QImage and DDS - i guess it can be used for
textures, but it requires adding more values to the QImage::Format enum.
After all, QImage is just an array of bits like any texture. Am i missing
something? (yep, volume texture is not a QImage, but it can be represented
using slices or as a separate class like QImage3d/QVolumeTexture)


>
> My 2 cents,
>
> --
> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180417/59d8db07/attachment.html>