saving with layers means that you’ll have a separate page for each layer in GIMP. Is that intended? If not, then uncheck “Save as layers” so that the shirt merged onto the profile picture.
Why do Okular and Gwenview not render this as expected, whereas GIMP does? I’m attempting to ascertain whether this is a defect of their image rendering pipelines, or whether it’s deliberate.
Multi-page TIFF files were often used as a common scanned image file format (scanning, faxing, etc). So each individual layer is a separate page.
A single‑page TIFF is often used simply to store images and pictures.
So, Gwenview (as an image viewer) displays only the first page.
And Okular, as a document viewer, displays all the pages of a document (just like in PDF).
The format itself is such that it’s difficult to distinguish a single‑page TIFF from a multi‑page one without opening it, since they have the same mimetype.
So there’s no error here.
It’s just that when GIMP launches a multi‑page document (including PDF), it asks the user how exactly to interpret it. As layers of a single image, or as separate images (pages). After all, GIMP is a raster editor, not a photo viewer.
@sgakerru, if TIFF does not support layers, and, instead, supports pages, the “error” appears to be that GIMP is incorrectly referring to pages as layers, and incorrectly rendering them atop one another. Surely it should not attempt to misuse what the format supports, lest compatibility be ruined. One might as well utilise an XCF file.
So, I guess these can be either layers or individual images.
I wouldn’t say that GIMP is referring to something incorrectly. After all, when launching a TIFF document, it offers to open it either as a single image with several layers or as several separate images. That is, it’s up to the user’s choice; GIMP itself doesn’t impose anything.
@sgakerru, I appear to be significantly less familiar with the TIFF standard[s] than you are. Consequently, to summarise, are you stating that the TIFF standards explicitly state that its multi-entity storage system is allowed to be interpreted, by the renderer, as a layer or page, interchangeably (albeit mutually exclusively)?
If so, the justification for that decision is nigh incomprehensible; what relation do layers and pages have? I ask because one is for horizontal organisation, whereas the other is for vertical organisation. They are not conceptually interchangeable.
I’m not sure how familiar you are with .svg, .ai, .afdesign/afpub/afphoto, etc., but basically, a file format can support multiple ways of presenting itself to apps, and the apps can choose to allow and use all the methods or only one.
An SVG file can be opened having both layers and pages, or only one, or as having no layers or pages at all (technically it would have a single layer).
As another example: Affinity’s file formats above, even before they merged the suite into one app, could all be opened in/by any of the apps in the suite.
So, again, basically the file formats says, “I can be anything you want me to be” and the app says, “I only need you to be a paged document.”
I can’t say for sure how this was intended in the standard.
Based on my observations, it’s usually individual pages, not layers of a single image.
Just don’t forget that layers in GIMP are just a way to edit a multi‑page file. The situation is similar with PDF. So, in GIMP, if you want to create a multi‑page TIFF, you add different images as layers and then save it with the “Save layers” option.
@ddnnacheta, I am more familiar with SVG than I am TIFF, although not particularly so with any of these. However, an interpreter that ignored an SVG’s request to render its elements on specific pages or layers would certainly be considered to be non-compliant.
I hope that you understand how difficult believing, that I have correctly understood you, is, considering how non-sensical, the conflation of functionality, that you purport, is…
That would mean that one cannot create a multi-page TIFF with a single layer, nor a multi-layer TIFF with a single page. No wonder it is so uncommon. If anyone knows of an alternative image format, which supports as much metadata as TIFF does, but sanely supports at least layering (for I’ve little use for pages), I shall be glad to know.
There may be more than one IFD in a TIFF file. Each IFD defines a subfile. One
potential use of subfiles is to describe related images, such as the pages of a fac-
simile transmission. A Baseline TIFF reader is not required to read any IFDs
beyond the first one.
So it suggests that multiple pages is one thing that the subfile structure can be used for, but doesn’t prescribe that it’s the only one.
As far as I can see (but I could well be missing something), the standard also doesn’t define any metadata fields which would specify what it is that the subfiles represent.
So it seems indeed that the reader has to know the writer’s intent, in order to correctly interpret the file.
That said, there seem to be a lot of defined metadata fields that the writer and reader could agree to (ab)use to communicate information like “how many layers per page, and how are the layers and pages arranged as subfiles?”
@ddnnacheta, those generalisations are not wholly accurate. Frequently, the lack of a publicly-available standard causes a “proprietary” format to be misused.
@pg-tips, thank you. I agree, having now read your cited excerpt. That is so uselessly vague that any implementation may be compliant. I shall avoid multi-IFD TIFFs hereafter.
