[Development] qdds image format

Иван Комиссаров abbapoh at gmail.com
Tue Apr 17 13:21:25 CEST 2018


Ok, there's another problem with QImage - ARGB64 and friends... This can be
solved adding QImage::pixel64() or something like that... or use QTexture
with 64bit "pixel"

2018-04-17 11:48 GMT+03:00 Иван Комиссаров <abbapoh at gmail.com>:

>
>
> 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/9adddafb/attachment.html>


More information about the Development mailing list