[Development] Imageformats v2

[Konstantin Ritt]

2015-05-19 22:12 GMT+04:00 Rutledge Shawn <Shawn.Rutledge at theqtcompany.com>:

> I think the new API should have multi-page support.  It would be useful
> for pdf, djvu, multi-page tiff, and for looking at individual frames of
> animated gif, png, etc., to the extent that we write plugins for those.
>

IIUC, this already covered by the idea: since we can not (currently?)
support animated "pages", we treat both a multi-page tiff and an animated
gif as a document with N "frames".


> I wrote a QQuickImageProvider for PDF (using poppler), but requestImage
> takes only an “id” string to identify the image.  So I had to make up a
> composite id containing both the filename and the page number.  (much like
> a URL format would be, if you had to request multiple pages from a web
> server)  So that’s the next API that needs to have some support for paging.
>
> Can “frame” be considered the same as “page”?  But I see that you also
> have a subimage concept in mind.
>

IMO, sub-images concept only makes sense when we have layers concept: i.e.
we could have a layer with several image resources, where each resource
could have different size/depth/format + might be transformed and stacked
somehow (so we'll need their z-order and blending mode params at very
least).


> Sometimes (as in icon files, or in any kind of file that also includes a
> smaller preview image) the sub images would be the same thing at different
> resolution, right?  That is orthogonal to the idea of paging: a PDF file
> can have multiple pages, and also embedded thumbnails for each page.  In
> order for an image format plugin to be enough to write a PDF reader
> application, it would need to support paging, and also getting the
> thumbnails for the pages.
>
> In QQuickImageProvider::requestImage, requestedSize can also be given.  So
> that’s one way to specify a thumbnail: if the available thumbnail is near
> enough to requestedSize, return that instead.  The API anyway does not
> guarantee that you get exactly the size that you ask for.
>

What you described sounds more like mipmap support. We can not say "this is
a thumbnail for page N" by looking at the image size only.


> Eventually we could get to the point that a plain Image in QML could be
> used as a PDF viewer, all by itself.  It would also need a paging API.


Then, maybe something like `
property int page: 0
readonly property int pagesCount: pdf.framesCount
ImageDocument {
    id: pdf
    source: "path/to/file.pdf"
}
Image {
    id: pageViewer
    source: pdf
    frame: page
}
Image {
    id: pagePreview
    source: pdf
    frame: page
    mipLevel: -1
}
` would fit better?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150519/d6d88dca/attachment.html>