[Development] [Interest] Imageformats v2

Иван Комиссаров abbapoh at gmail.com
Wed May 20 17:27:43 CEST 2015

2015-05-20 15:18 GMT+03:00 André Somers <andre at familiesomers.nl>:
>   Problem is that you cannot show your _own_ message anymore. I might
> want to choose a different wording in a message that I'd like to show to my
> end user than something a Qt engineer choose. I also might like to offer
> different choices for different results: a Retry may make sense in case of
> a network error, but not in case of an unrecognized file type error...

Ok, i think i should add a enum:)

>   I think that it makes sense to attempt to load a header if it exists.
> If not... Not sure. Probably need to read the entire file in order to
> determine what it contains?

Any other opinions? I vote for dropping separate header reading:)

>     You would not need a separate reader and writer. You would need to
> have an ImageDocument be specific about the type of image it represents.
> Your operation would, I think, look like this:
> ImageDocument imageDoc("thefile.png"); //imageDoc gets type from file: png
> qDebug() << imageDoc.mimeType(); //outputs "image/png"
> imageDoc.convert("image/jpeg"); //convert in-place to jpg document
> qDebug() << imageDoc.mimeType(); //outputs "image/jpeg"
> imageDoc.saveAs("thefile.jpg");
> or
> ImageDocument imageDoc("thefile.png");
> qDebug() << imageDoc.mimeType(); //outputs "image/png"
> imageDoc.converted("image/jpeg").saveAs("thefile.jpg"); //convert in-place
> to jpg document
> qDebug() << imageDoc.mimeType(); //outputs "image/png" as imageDoc itself
> did not change
> No need to say goodbye to your ImageDocument design and create your own
> storage?

What i actually ment, there is no place where you can store data regardless
the capabilities (some kind of ICanEverythingDocument)

I would not like it much if information is silently dropped. If you make
> the conversion explicit, it is also explicit what features are available
> for the type you have now. How else are you going to expose that
> information?

I'm not sure, but typically one knows the type of the document only when
saving (i.e. file is opened, user changes it, than calls "save" dialog).
You don't know which format the document will be saved. IMHO.

> That is an artefact of your choices, not inherent in how it could be. If I
> rewrite you example using my suggested API, you'd end up with something
> like this:
> Document doc("1.dds"); // has mipmaps, depth and "frames"
> QVector<QImage> resources; //lets be explicit what we return when
> discussing API...
>  resources = doc->images().slice(5).frame(0).mipmap(1); //in any order,
> resources is QVector<QImage>
>  resources = doc->images().slice(0).mipmap(2); // returns all frames at
> depth 0
> resources = doc->images().mipmap(3); //returns all images of all depths
> But also:
> QImage firstPage = doc->images().page(0).first();
> QImage secondPage = doc->images().page(1).first();

I need to think about that option, thanks for an idea of returning same
class as a slice. I had an idea of multiple-dimension array, but indexing
was weird.

>     If you want to set certain meta data attributes on all images in the
> document in one go, then that still isn't the same as setting it on the
> document itself, right? I'd keep them separate for now. You can always add
> convenience API that does that later on. Start out with the minimum, built
> up from there in later releases.

I'm hust trying to cover recent limitations:) Separate options are one of

>   So?
> The image plugin would return an error on writing I'd think? Or even
> isValid() would go to false? But it depends on the image format what is to
> be considered valid right? As those are pluggable, I don't think your
> generic API should restrict the options.

I'd prefer that API is easy to use in terms that you can't create invalid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150520/6446fb33/attachment.html>

More information about the Development mailing list