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 Иван Комиссаров <[email protected]>: > > > 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
