[Development] Imageformats v2

[Rutledge Shawn]

On 19 May 2015, at 21:00, Konstantin Ritt <ritt.ks at gmail.com> wrote:
> 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 thought so.
 
> 
> 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.

Some PDF viewers are rendering their own thumbnails anyway, and ignoring the built-in ones, because built-in thumbnails are often missing, and if they exist they have a fixed smallish size.  So in practice it works well enough to translate a requested image size into a decision: to use the built-in thumbnail which is close enough in size (saving some CPU time), or to just render the actual size as requested.  (PDF is a complex case compared to other image formats, because it can contain vector graphics, text etc.  But there are other vector graphic formats which can contain raster thumbnails.)  Some formats (like ico and icns) provide several sizes in the same file, so it’s again a matter of choosing the closest one to what was requested.  And some formats can efficiently provide a smaller image using a subset of the data rather than having to take the maximum resolution and scale it down, so again, choose the closest available size.  Whether or not the application chooses to treat one particular size as the “thumbnail” resolution is just an application detail.  The thumbnails might be expected to be scalable anyway in some particular UI (as in Finder on OS X), but then there is some lag while the re-rendering is done after each change in scale.  So if you ask for 72px and a PDF happens to be using that size for page thumbnails, great, let’s use it; but if you ask for 120px, then the page needs to be rendered at that resolution, although 72px would be OK temporarily (scaled up to 120px) while the re-rendering takes place.

So maybe it would be useful to have a flag specifying whether it’s OK to use close-enough sizes, or to require that the image be returned at exactly the requested size.

Of course if everyone wants an additional API to specifically limit the output to whatever is identified as a thumbnail in image formats which provide them, that’s probably a good idea too.  But then you would often fail to get an image at all, and need to follow up by requesting a non-thumbnail anyway.

> 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
> }

ImageDocument has its uses, but I don’t think it should be required for all use cases.  A full-featured PDF viewer needs such an object to access the text objects on each page (with bounding boxes), document metadata etc.  A less full-featured one would not.  And anyway the backend for it is outside the scope of the imageformats API, isn’t it?  PDF has a very extensive feature set, beyond what most image formats provide.  So more like import package.pdf and then have a PdfDocument, which links to whatever PDF library on its own.  Whereas simple all-format image viewers wouldn’t need those features, so they could get by with Image.

So I’d add both frame and frameCount to Image, which would be enough in this example, and then you don’t need the ImageDocument for such a simple use case.