2018-04-17 11:02 GMT+03:00 Giuseppe D'Angelo <[email protected]>:
> 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 | [email protected] | 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 > >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
