Re: [Development] Imageformats v2

[Konstantin Ritt]

2015-05-19 22:12 GMT+04:00 Rutledge Shawn :

> 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?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Imageformats v2

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

Thanks for reply.

Yes, frames should actually be renamed to something more generic (array 
element? page? resourceCount? - i couldn’t find the right name yet). Actually, 
DDS doesn’t support animation, but it supports texture arrays which should be 
implemented using "frames".

I didn’t think about reading pdf files as an image, but why not… Thumbnails 
seems pretty close to mipmaps. Can there be multiple thumbnails of the 
different size for a page?

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

19 мая 2015 г., в 21:12, Rutledge Shawn  
написал(а):

> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Imageformats v2

[Rutledge Shawn]

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.

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.

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.

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.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Imageformats v2

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

Hello everybody!

Recently i’ve started a project of a new imageformats API. The reasoning is 
that there are a lot of limitations in the current API: no way to save file 
containing an array of images, bad error handling, no support for the EXIF. 
Implementing those features requires ABI breakage of the QImageIOHandler class 
(adding new virtual functions, at least). So i’ve decided to start from scratch.

Code is located here 
https://github.com/ABBAPOH/imagedocument/tree/master/src/lib 
 and is just an 
API rather working implementation.

Let me describe current API and the ideas behind it.

The core class is the ImageDocument - this is the replacement of the 
QImageReader/QImageWriter. Reader and writer has similar API and implemented in 
the same way, so i’ve decided to merge them into one class. ImageDocument 
inherits QObject so it can connect to the QIODevice signals and read image 
while it downloads from network, for example. So, device() and fileName() 
methods are similar to the corresponding methods in reader/writer.

Instead of QByteArray format() i choosed to use QMimeType. With mimetypes, we 
don’t need to iterate over handlers like we do now in attempt to find suitable 
one. This code is already written in mimetypes, so all we need is to find 
suitable mime type.

bool hasError()/QString error() - no comments.

bool open(OpenMode) is an attempt to get rid of the QImageReader::canRead() 
function. Unlike canRead(), open can not only check if data is valid, but also 
read the header of an image so we can know how many data acually present. 
OpenMode can be Read/Write or both; right now, WriteMode can only be checked by 
handler if it supports writing (i.e. can be used instead of 
QImageIOPlugin::CanWrite).

close() is symmetrical for open() not sure if it really needed.

capabilities() method returns capabilities (yep) of a format, see 
CapabilityFlag enum.

Conceptually, ImageDocument is a 2D array (of size is 
mipmapCount()*frameCount()) of ImageResources plus meta data (ImageMeta class). 
The first dimension of the array is mipmaps (SupportMipmaps flag - can be used 
by Ico, Icns, DDS image formats), the second dimension is the frame number 
(actually, that should be something like array index) - can be used by GIF, DDS 
(yes, dds have both mipmaps and frames).

ImageResource can be a single image, a cube texture (Capabilities::SupportSides 
flag) or a VoumeTexture (Capabilities::SupportSlices flag). Type is described 
by ImageResource::Type enum. In the first case, Resource contains a single 
image, in the second case - array of 6 images (for each side of a cube) and in 
the third case it contains array of images of size ImageResouce::depth.

Also, both ImageResource and ImageDocument have metadata associated with it 
(ImageMeta class). The duplication is needed for 2 reasons: first, some formats 
can support different meta for each resource (icns), some has the same meta for 
all resources (DDS); second, meta in document can be used if you don’t need to 
set meta for each resource separately.

ImageDocument::supportsOption() returns options supported by the document, 
supportsResourceOption() returns options supported by resources (typically, 
resource options depend on the subtype of a resource, at least for Icns).

What i dislike now is that the Document a 2D array. Maybe i should move mipmaps 
dimension to a separate class Mimpap {QVector frames;} ?

Next, i don’t have support for layered images (PSD?). With current API, they 
can be implemented in 2 ways - either ImageResource is a Layer containing list 
of elements with layer metadata (position on a layer, blending options, 
z-order). Or ImageResource is an element on a layer and the layer it belongs is 
an index/name in resource’s metadata.

So, i want to know an opinion of the people familiar with imageformats about 
the API - what should i change/add/remove?

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development