[Development] Fwd: Imageformats v2

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

Hm, i pressed wrong button when replying to the letter:)

---------- Forwarded message ----------
From: Иван Комиссаров <abbapoh at gmail.com>
Date: 2015-05-20 12:06 GMT+03:00
Subject: Re: [Development] Imageformats v2
To: André Somers <andre at familiesomers.nl>




2015-05-20 10:05 GMT+03:00 André Somers <andre at familiesomers.nl>:

>  Иван Комиссаров schreef op 19-5-2015 om 19:43:
>
ImageDocument doesn't need to inherit QObject in order to listen to
> QIODevice signals of course. First of all, it could have rather than be a
> QObject, and second of all you can connect to almost anything callable
> nowadays. I'm not saying that being a QObject is a bad thing per se, just
> that your argument for it isn't all that convincing to me.
>
> Are you sure a QString as an error() is the best choice? There are other
> places in the Qt API where an enum is used instead. I think an enum would
> probably be a better choice: it is easier to deal with in errorhanding (no
> string comparisons needed; localization issues).
>

Please, provide me an example how to handle QImageReader::DeviceError,
QImageReader::UnsupportedFormatError or QImageReader::InvalidDataError.

Would it then not be better to be explicit about this, and just call it
> like that: bool readHeader()? I don't think it is a good idea to try to
> emulate the QIODevice API for something that isn't one. It is just
> confusing IMHO. What happens if the ImageDocument can, but the underlying
> QIODevice cannot write?
>

What happens if user forgot to call to readHeader()? In case document is
not opened, it's quite easy - we reject any further operations. For now,
open() checks open flags of the device and tries to reopen device in write
mode if necessary. It fails if device cannot be opened.


>
> So what does it actually do?
>

Nothing for now:) But it can write end markers of the file and close the
device.

>   capabilities() method returns capabilities (yep) of a format, see
> CapabilityFlag enum.
>
> Hmm? The capabilities of the document? Don't the capabilities belong to
> the format instead? Judging from the API you have presented so far, I got
> the impression that an ImageDocument could represent image containers in
> any format. Now, it seems like the capabilities of the format are leaking
> into the document. How do you construct a document from scratch then? Where
> do the capabilities come from? Can I use ImageDocument to convert between
> two different formats?
>

So, do you suggest move those options to ImageIoHandler? I don't think this
is good idea. Right now, users are forced to use "private" class
QImageIOHandler only for option flags enum. I think, that class should be
used only to create new handlers and typical user of a Document shouldn't
know about it.
Typicall usecase is - open document for writing, check what capabilities
are present and add resources to the document. But you can add various
resources first, then open for writing and call write().
Yes, this is possible to resave document in the other format, hanlder just
should drop anything it doesn't support. We have no mipmap support - ok, we
just save first mipmap. We have no volume texture support - ok, just save
first slice.
There should be an API that will allow to access those "default" images.


> I am wondering if this is really the right slicing of the possible
> contents. Pages were already mentioned before. Do you really need to be
> able to have the document represent a 2D array of vectors of images (in
> case you are using frames, mipmaps with volumne textures)? Are there image
> formats like that that we need to support in Qt? It also results in an
> overly complicated setup for the simple use cases I think.
>

That's the best way i found.
For the simple usecase, there can be Document::image() method that simply
returns a "default" image (of mipmap 0, frame/page 0, slice 0).


>
> Might it not be better to have ImageDocument contain a collection of
> QImages directly, that can have different kinds of relationships with each
> other and that you can somehow query for if you need to?
>

I was thinking about that. DDS can have up to mipmapCount*frameCount*6. How
do you suppose to get all sides for frame 10, mipmap 5? There was an idea
to store mipmap/frame/side in ImageMeta::options and to use something like
document->filterResources(options). But there are problems - i already have
Document::meta. I can write something like doc->meta.setOption(Side,
PositiveX), but this makes little sense, API is confusing.


>
> For an application I am working on at work, I actually wrote a document
> class a bit like that. The document contains a series of images: images
> made of the left or right eye, from different angles, in different wave
> lengths (IR, green laser, color - and these are actually really different
> types of images!) in any combination. The set can contain any of these, but
> need not contain all. We keep them all in a single ImageCollection that you
> can simply query for things like "which eyes occur in the set" but also
> filter back using a method filtered() with overloads for all the different
> dimentions we have, returning just another image collection. Perhaps
> ImageDocument could work in a similar way to collapse pages, frames, layers
> and mipmaps into?
>

Too complex indexation. How do i supposed to control that EACH mipmap have
the same number of frames as document->frameCount(). I didn't find suitable
solution.


>
> Well... if you want to support layers, then perhaps you need to support
> much more. For instance: are you sure that all layers are bitmap-type
> layers? How are layers blended? Perhaps all that goes a bit too far for
> starters.
>

That's why i initiated the discussion - to ask someone with knowledge of
other formats about ideas. I'm not sure we really need to support layers
(TIFF has something like layers, but they are pretty simple - AFAIK only
rgb and alpha is separated; we can just blend them together)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150520/a0d09087/attachment.html>