[Interest] [Development] Imageformats v2

[André Somers]

Иван Комиссаров schreef op 20-5-2015 om 11:06:
>
>
> 2015-05-20 10:05 GMT+03:00 André Somers <andre at familiesomers.nl 
> <mailto: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.
Show different error messages for instance. Invalid data points to a 
corrupted file. That is not the same as just not recognizing the file 
format or having a network connection break in the middle of reading.
>
>     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.
Perhaps it should just read the header directly when opening from 
file/iodevice and have an isValid() method or something like that?

>
>     So what does it actually do?
>
>
> Nothing for now:) But it can write end markers of the file and close 
> the device.
Not sure if that is a good idea. If you didn't open the device, you 
should not close it.

>>     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.
Fair enough. But that means that an ImageDocument should have a clear 
type at any time. That means you either create it with that type, get 
the type from the image you are reading, or convert to that type.

> 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().
Well, you can if you know the capabilities of the file you want to 
create, I'd say. I don't think I would allow adding resources to a file 
if the format can't support those resources.

> 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.
Thinking about this, I think I'd make the conversion explicit. If you 
loaded a multipage TIFF and want to save as a normal PNG, you could 
either have a void convert(QMimeType type) that converts the current 
document to the new value (dropping unsupported features in the process) 
and/or have a ImageDocument converted(QMimeType type) function that 
creates a new ImageDocument in the requested format based on the current 
document. Then, save _that_ document.

Perhaps you/the user/the file format plugin could even offer different 
options of how to deal with the degradation. Layers might be flattened 
to a single image, meta data from a specific image stored in the main 
meta data or vise versa, pages glued together to form a single image...

>     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?
With something like document.images().frame(10).mipmap(5)? That would 
result in a list of 6 images for the requested frame and mipmap.

If images() returns a QVector<QImage>, you could use the same trick as 
used in QByteArrayList to add some special filtering methods on it 
without actually subclassing QVector<QImage>.

frame() and mipmap() (and side() and page() and layer() and whatever 
else one might come up with) could act as filtering functions that again 
return a list of images that has these methods.

> 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.
Well, I don't know how your Meta things work of course, so I cannot 
comment on that. To me it makes little sense to set a meta property that 
belongs to a specific image on a document directly, but that may be my 
misunderstanding of your design.
>
>
>     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.
I think it is actually simpler than forcing a 2D array onto image 
document formats that don't benefit from it.

> How do i supposed to control that EACH mipmap have the same number of 
> frames as document->frameCount(). I didn't find suitable solution.
Why would you need to control that? If an image format requires it, then 
that image format should impose that limit (or even auto-create the 
missing ones?) but I don't see why it should be a general limi Perhaps 
there are formats where it is possible that one page has a mipmap, while 
others don't? Just the first page for instance to provide a quick preview?

André

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150520/4ca2ef87/attachment.html>