Re: [Development] qdds image format

[Sean Harmer]

On 17/04/2018 15:33, Иван Комиссаров wrote:
At the point i wrote the plugin, my usecase was simple - to convert 
plain QImages to and from DDS icons (used in starcraft2, which uses 
quite a few formats DDS can handle).

But yes, i forgot floating point textures.
Compressed textures (DXTN/ATI2) are just compressed (a)rgb32, nobody 
uses compressed jpeg, it is decompressed before usage (correct me if i'm 
wrong, but videocards uses DDS because it's decompression algorithm can 
be easily implemented in hardware)


DDS is just a container format. Peppe's point stands, QImage and friends 
are the wrong vehicle for supporting this. They simply do not offer 
enough degrees of freedom in the API to do so properly. And adding them 
would be changing what QImage is designed for.


QImage is designed to represent a single image in one of a few supported 
formats. Proper texture support needs to be able to address images by 
mip level, array layer and cubemap face in any of the formats supported.


The compressions used by various formats supported within a DDS (or KTX) 
file are designed so they can be decompressed on the fly for a small 
block of pixels. These block compression algorithms do not offer such 
on-disk savings as png/jpeg but are much easier to sample from in access 
patterns typically required by fragment shaders.


I'm not saying a tool to convert to/from dds/some other format would not 
be useful. Just that QImage is the wrong way to approach this due to the 
above.


Sean



2018-04-17 14:28 GMT+03:00 Giuseppe D'Angelo >:


On 17/04/18 13:21, Иван Комиссаров wrote:

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"


And a bunch of packed formats not currently supported, and floating
point channels, and compressed texture formats. I stand my point:
DDS files are not meant to be handled by QImage.

What is your use case exactly for wanting this support?

Cheers,

-- 
Giuseppe D'Angelo | giuseppe.dang...@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




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Thiago Macieira]

On Tuesday, 17 April 2018 07:35:44 PDT Konstantin Tokarev wrote:
> FWIW, hardware decoding of JPEG is usually supported by devices featuring
> hardware video decoding support.

But that's still decompressing it. You're just using the HW to do it faster.

The only use-case I can easily think of for using the compressed JPEG data is 
lossless rotation in multiples of 90°.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Konstantin Tokarev]

17.04.2018, 17:33, "Иван Комиссаров" :
> At the point i wrote the plugin, my usecase was simple - to convert plain 
> QImages to and from DDS icons (used in starcraft2, which uses quite a few 
> formats DDS can handle).
> But yes, i forgot floating point textures.
> Compressed textures (DXTN/ATI2) are just compressed (a)rgb32, nobody uses 
> compressed jpeg, it is decompressed before usage (correct me if i'm wrong, 
> but videocards uses DDS because it's decompression algorithm can be easily 
> implemented in hardware)

FWIW, hardware decoding of JPEG is usually supported by devices featuring 
hardware video decoding support.

>
> 2018-04-17 14:28 GMT+03:00 Giuseppe D'Angelo :
>> On 17/04/18 13:21, Иван Комиссаров wrote:
>> 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"
>>
>> And a bunch of packed formats not currently supported, and floating point 
>> channels, and compressed texture formats. I stand my point: DDS files are 
>> not meant to be handled by QImage.
>>
>> What is your use case exactly for wanting this support?
>>
>> Cheers,
>>
>> --
>> Giuseppe D'Angelo | giuseppe.dang...@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
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

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

At the point i wrote the plugin, my usecase was simple - to convert plain
QImages to and from DDS icons (used in starcraft2, which uses quite a few
formats DDS can handle).
But yes, i forgot floating point textures.
Compressed textures (DXTN/ATI2) are just compressed (a)rgb32, nobody uses
compressed jpeg, it is decompressed before usage (correct me if i'm wrong,
but videocards uses DDS because it's decompression algorithm can be easily
implemented in hardware)

2018-04-17 14:28 GMT+03:00 Giuseppe D'Angelo :

> On 17/04/18 13:21, Иван Комиссаров wrote:
>
>> 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"
>>
>
> And a bunch of packed formats not currently supported, and floating point
> channels, and compressed texture formats. I stand my point: DDS files are
> not meant to be handled by QImage.
>
> What is your use case exactly for wanting this support?
>
> Cheers,
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@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
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Jason H]

> From: "Giuseppe D'Angelo" 
> On 17/04/18 13:21, Иван Комиссаров wrote:
> > 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"
> 
> And a bunch of packed formats not currently supported, and floating 
> point channels, and compressed texture formats. I stand my point: DDS 
> files are not meant to be handled by QImage.
> 
> What is your use case exactly for wanting this support?

Sorry to hijack this, but adding YUV support to QImage (or anywhere in Qt, 
really) would be a welcome addition for those of is wanting to capture images 
from video devices. I keep having to code my own YUV decoder for whatever 
frames I need to support (Currently, NV21, BGR32, though in the past YUV420). 
I'm sure the trolls could do a better job at it than I. Having them supported 
would be a boon to anyone using QVideoFilterRunnable, QAbstractVideoFilter, 
QVideoProbe classes.
 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Giuseppe D'Angelo]

On 17/04/18 13:21, Иван Комиссаров wrote:
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"


And a bunch of packed formats not currently supported, and floating 
point channels, and compressed texture formats. I stand my point: DDS 
files are not meant to be handled by QImage.


What is your use case exactly for wanting this support?

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

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

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

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

Re: [Development] qdds image format

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

2018-04-17 11:02 GMT+03:00 Giuseppe D'Angelo :

> 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.dang...@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
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Giuseppe D'Angelo]

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.



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.


My 2 cents,
--
Giuseppe D'Angelo | giuseppe.dang...@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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

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

> 16 апр. 2018 г., в 16:03, Giuseppe D'Angelo  
> написал(а):
> 
> On 16/04/18 12:23, Иван Комиссаров wrote:
>> So, how those issues are checked? Any tool or what?
> 
> 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?

Looking at the code, i found at some bugs (unchecked using scanline when image 
is null), i can easily fix that.
A multiimage files are not implemnted (the code is supposed to read first 
image, still i don’t see why it can crash, i’ll try to generate such file and 
see what happens)


> 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:(
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.
I don’t like reimplementing a wheel but i constantly have to because of that 
0.01% of that «features that nobody needs»:)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Giuseppe D'Angelo]

On 16/04/18 12:23, Иван Комиссаров wrote:

So, how those issues are checked? Any tool or what?


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).


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.


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

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

So, how those issues are checked? Any tool or what?

2018-04-16 0:41 GMT+03:00 Thiago Macieira :

> On Sunday, 15 April 2018 12:59:35 PDT Giuseppe D'Angelo wrote:
> > Hello,
> >
> > Il 15/04/2018 18:14, Иван Комиссаров ha scritto:
> > >> The usual amount of parsing a file without doing bounds checks, so
> making
> > >> the user vulnerable to crashes / code execution / overflows and the
> > >> like.>
> > > Are there any tickets on Jira related? All tickets i found are fixed
> and
> > > closed long ago (Qt5.5)
> > I'm not sure if it was reported on Jira or through a security
> > notification. I'm thinking about the latter, around the time where we
> > fuzzed Qt's image formats.
>
> I don't think it was reported against DDS. We fuzzed all the image format
> readers after a report against one of them.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Thiago Macieira]

On Sunday, 15 April 2018 12:59:35 PDT Giuseppe D'Angelo wrote:
> Hello,
> 
> Il 15/04/2018 18:14, Иван Комиссаров ha scritto:
> >> The usual amount of parsing a file without doing bounds checks, so making
> >> the user vulnerable to crashes / code execution / overflows and the
> >> like.> 
> > Are there any tickets on Jira related? All tickets i found are fixed and
> > closed long ago (Qt5.5)
> I'm not sure if it was reported on Jira or through a security
> notification. I'm thinking about the latter, around the time where we
> fuzzed Qt's image formats.

I don't think it was reported against DDS. We fuzzed all the image format 
readers after a report against one of them.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Giuseppe D'Angelo]

Hello,

Il 15/04/2018 18:14, Иван Комиссаров ha scritto:

The usual amount of parsing a file without doing bounds checks, so making the 
user vulnerable to crashes / code execution / overflows and the like.


Are there any tickets on Jira related? All tickets i found are fixed and closed 
long ago (Qt5.5)


I'm not sure if it was reported on Jira or through a security 
notification. I'm thinking about the latter, around the time where we 
fuzzed Qt's image formats.



What need to be done to return the plugin to the default build?


Build it yourself; as far as I know it's still shipped as part of 
qtimageformats.


I’m asking because I’m, the original author of the DDS plugin and I’m 
disappointed my work is thrown away:(


Sorry about that... just a matter of evolution of the code. But, as I 
said, the code itself should be still shipped, just not built by default.



The reason i started the work is to convert to/from DDS files because existing 
converters (PS/GIMP plugins and microsoft tool are not ideal, GIMP plugin is 
really buggy). However, i stucked because of the limitations of the 
QImageWriter API (which can’t be changedun till Qt6).


What do you mean? What has Qt to do in terms of converters?

From my personal experience texconv / texassemble are probably the best 
tools in terms of creating DDS files. Recently ImageMagick also has got 
some support, however I found it still extremely buggy.




I can fix the security issues and move the dds reading/writing code to the 
separate lib so it can be shared with Qt 3d (i saw the duplication of the 
DDSHeader at least) and not be dependent on the QImageIoPlugin API which is 
flawed.


In the broader plan of things Qt should get some convenience APIs for 
loading from texture files; these APIs should sit in QtGui and then be 
used by Qt3D, QtQuick and so on. I don't see it useful to revamp the DDS 
image loader just for this purpose.


To say it all: such a thing in QtGui (QOpenGLTexture::loadFromFile?) 
should just use GLI or some other similar library, so we make it SEP and 
also support a bunch of formats in one go.


My 2 cents,
--
Giuseppe D'Angelo | giuseppe.dang...@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



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

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

> 15 апр. 2018 г., в 18:59, Giuseppe D'Angelo  
> написал(а):
> 
> Il 15/04/2018 17:32, Иван Комиссаров ha scritto:
>> Hello, what happened to the qdds image plugin?
>> I found the note in the docs: "For security reasons, the Direct Draw Surface 
>> (DDS) handler is not built by default since Qt 5.8" but could not find any 
>> open issues.
>> Does anyone know what are those "security reasons"?
> 
> The usual amount of parsing a file without doing bounds checks, so making the 
> user vulnerable to crashes / code execution / overflows and the like.

Are there any tickets on Jira related? All tickets i found are fixed and closed 
long ago (Qt5.5)

> 
>> What need to be done to return the plugin to the default build?
> 
> Build it yourself; as far as I know it's still shipped as part of 
> qtimageformats.

I’m asking because I’m, the original author of the DDS plugin and I’m 
disappointed my work is thrown away:(

> 
> Apart from the quality of the implementation, there is close to zero reasons 
> to use DDS as an image format plugin in Qt: a DDS file represents a texture, 
> not an image (so the generic access through QImageReader isn't enough), and 
> QImage can't represent the formats that you can store in a DDS anyhow.

The reason i started the work is to convert to/from DDS files because existing 
converters (PS/GIMP plugins and microsoft tool are not ideal, GIMP plugin is 
really buggy). However, i stucked because of the limitations of the 
QImageWriter API (which can’t be changedun till Qt6).
I can fix the security issues and move the dds reading/writing code to the 
separate lib so it can be shared with Qt 3d (i saw the duplication of the 
DDSHeader at least) and not be dependent on the QImageIoPlugin API which is 
flawed.

> 
> Note that the above has nothing to do with DDS support in Qt3D, which has 
> never used the image format plugin.

Yep, it used the DDSHeader only when i looked at the code
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdds image format

[Giuseppe D'Angelo]

Il 15/04/2018 17:32, Иван Комиссаров ha scritto:

Hello, what happened to the qdds image plugin?
I found the note in the docs: "For security reasons, the Direct Draw 
Surface (DDS) handler is not built by default since Qt 5.8" but could 
not find any open issues.

Does anyone know what are those "security reasons"?


The usual amount of parsing a file without doing bounds checks, so 
making the user vulnerable to crashes / code execution / overflows and 
the like.



What need to be done to return the plugin to the default build?


Build it yourself; as far as I know it's still shipped as part of 
qtimageformats.


Apart from the quality of the implementation, there is close to zero 
reasons to use DDS as an image format plugin in Qt: a DDS file 
represents a texture, not an image (so the generic access through 
QImageReader isn't enough), and QImage can't represent the formats that 
you can store in a DDS anyhow.


Note that the above has nothing to do with DDS support in Qt3D, which 
has never used the image format plugin.


Hope this helps,
--
Giuseppe D'Angelo | giuseppe.dang...@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



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qdds image format

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

Hello, what happened to the qdds image plugin?
I found the note in the docs: "For security reasons, the Direct Draw
Surface (DDS) handler is not built by default since Qt 5.8" but could not
find any open issues.
Does anyone know what are those "security reasons"?
What need to be done to return the plugin to the default build?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development