Иван Комиссаров schreef op 20-5-2015 om 11:06:
2015-05-20 10:05 GMT+03:00 André Somers <an...@familiesomers.nl
<mailto:an...@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é
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
