The particular stumbling block seen in the above linked bugreport is probably gzip compression of tiles which is one of multiple new capabilities XCF will have for GIMP 2.10, and its implementation is unlikely to change now that it has made its way into the xcf saving code. Another new change is unlikely to change is how 16bit integer, half and single float precision files are stored.

Do note that GIMP 2.9.x versions are development snapshots of the progress towards what will become 2.10 the next stable. GIMP tries hard to avoid incompatibilities for any XCF files, but in particular ones saved with stable versions like 2.6, 2.8 and the upcoming - likely this year - 2.10. For development series like the 2.9 series full archiveability of content is a bit more lax, and some earlier versions of 2.9.x saved files that master now renders differently. We are not even fully certain that the interpretation of integer values for instance for layer blending modes is final, but we are getting closer).

I think KDE (and anyone else just interedted in a preview) should simply
read a thumbnail. Problem is that we don't save a thmbnail yet :)
Also see bug 551262.

Providing a thumbnail wouldn't be much of a problem, let's start some
data gathering... how lare would an ideal thumbnail be for KDE's
purposes?

(In reply to Michael Natterer from comment #2)
> Providing a thumbnail wouldn't be much of a problem, let's start some
> data gathering... how lare would an ideal thumbnail be for KDE's
> purposes?

The largest size thumbnail as displayed in digiKam 5.5 (very recent version) has max dimension of 512px. This seems to me to be a good size for a thumbnail, allowing to downsize to smaller dimensions.

(In reply to Elle Stone from comment #3)
> The largest size thumbnail as displayed in digiKam 5.5 (very recent version)
> has max dimension of 512px. This seems to me to be a good size for a
> thumbnail, allowing to downsize to smaller dimensions.

And/or (as a user option?) store a flattened version of the full-size image, and let programs such as digiKam generate smaller thumbnails from the embedded flattened version of the XCF file, as per the suggestion in bug 551262?

I'd even say that 512px is a little on the large size. Personally I'd probably look more towards 256px.

In the context of a "thumbnail" the full size flattened version doesn't make any sense and is more than likely just a waste of space, imo.

(In reply to Pat David from comment #5)
> I'd even say that 512px is a little on the large size. Personally I'd
> probably look more towards 256px.
> 
> In the context of a "thumbnail" the full size flattened version doesn't make
> any sense and is more than likely just a waste of space, imo.

I use digikam to sort, locate, view, and open images. Digikam generates thumbnails from the images, which it can't do for GIMP XCF files. 

Digikam can use an embedded image upon request for viewing the "full-size" image, as well as for generating the actual thumbnail that digiKam displays when viewing thumbnails instead of a single full-size image, as for example raw file embedded jpegs, which normally are much larger than 512px.

As digikam's thumbnail size can be as large as 512px, I'm assuming various digikam users find this to be a useful size. I had no input into this decision, but I find the ability to make thumbs smaller or larger, and as large as 512px, to be very helpful when sorting images.

Digikam also allows to show the full-size image by clicking on the thumbnail, which is very useful when sorting/comparing to find which image is "a bit more this/a bit less that". Small images aren't useful for fine comparisions.

If GIMP embeds a full-size flattened image, then digiKam can generate the thumbnails from the full-size image. Then the user can resize the thumbnails up to 512px at the user's choice, and also view the full size single image.

If GIMP only embeds a 256px thumbnail, with no full-size flattened version, then users can't use digiKam to make fine comparisions. Instead they'll have to resort to opening the full XCF files with GIMP.

"Useful size" depends on the specific user task and workflow, and also on the user's screen size. It also depends on the user's vision - not everyone has 20/20 eyesight.

The main concern I have is in file size.  I think keeping a full-size flattened version is definitely too much.

If the idea is to store a flattened thumbnail, then the question is only what is the most appropriate size?

I don't personally use a DAM where I need such a large thumbnail but I don't have a good argument against those dimensions other than file size or use.

At some point you should probably actually open the file in an editor for a full-size view if it's _that_ critical.  My personal use-case is to get a quick view of the file itself - enough to see if I am dealing with one of interest to me enough to fully open in an editor.
…

> If GIMP only embeds a 256px thumbnail, with no full-size flattened version, then users can't use digiKam to make fine comparisions. Instead they'll have to resort to opening the full XCF files with GIMP.

Yes - that makes sense.  I don't know that a 512px size really adds much to a workflow that might be dealing with these sizes.  Just adding my thoughts.

(In reply to Pat David from comment #7)
> The main concern I have is in file size.  I think keeping a full-size
> flattened version is definitely too much.

Too much for what? I deal with very large layer stacks. One more flattened layer doesn't make any difference.

> > If GIMP only embeds a 256px thumbnail, with no full-size flattened version, then users can't use digiKam to make fine comparisions. Instead they'll have to resort to opening the full XCF files with GIMP.
> 
> Yes - that makes sense.  I don't know that a 512px size really adds much to
> a workflow that might be dealing with these sizes.  Just adding my thoughts.

Yes, 512px is too small for really seeing the difference between two similar files. The jpeg embedded in Sony A7 raw files is 1616 × 1080 pixels. This allows digiKam to make a thumbnail that can be viewed as up to 512px in size, and also allows to view a larger (more or less full screen on a 19" monitor) version of the embedded image. 

256px is considerably smaller than the largest (512px) thumbnail that digiKam can generate. And it's hugely smaller than the jpeg embedded in the A7 raw file.

A user choice regarding the size of the flattened preview would be nice:

* If one user mostly views thumbnails on a very small device, obviously they don't need a large thumbnail. 

* If another user generates multiple similar files (depending on the image, often I'll generate several versions of the same file, each with it's own XCF file or set of files), and wants to see larger flattened versions of the XCF files in their DAM software, then why would anyone want to limit the maximum size of the embedded flattened image to 256px?

There is also the issue of retina displays, which apparently need twice the size to display the same thumbnail/icon/image as a non-retina screen:

https://feedback.photoshop.com/photoshop_family/topics/maximize_file_compatibility_bloats_files_need_smaller_option:

"New OS X supports icons containing multiple images up to 1024 x 1024 pixels which will provide sharp images when displayed at various scales and are recommended for Retina displays."

This of course is entirely apart from the issue of digiKam users wanting to see larger flattened versions of their XCF files when they click on a thumbnail.

As an aside and in case it wasn't clear, digiKam allows to change thumbnail size "on the fly" from very small all the way up to 512px. It's not a matter of the user having to choose just one thumbnail size. 

I usually have the digiKam thumbnail size set to very small, but when I've located a given set of files, then I'll use larger thumbnail sizes, and eventually start going to full screen. I'm guessing this is a fairly common scenario with digiKam users. With only very small embedded image files in GIMP XCF files, digiKam users will only see blurry enlargements if they try to zoom in.

One reason to offer users the option to embed a full-size flattened image that can be extracted to disk is as a fall-back for users who might eventually no longer have GIMP installed.

PhotoShop CS versions offered this option as "compatibility mode", which I didn't use as it did make the file size larger, at a time when disk storage was a lot more expensive than now. Consequently, when I switched to Linux, digiKam couldn't show previews for my old PhotoShop PSD files. So I ended up deleting most of them because "guessing" what file contained what was time-consuming, and most of the files weren't worth saving anyway. But a few of them had work I would have liked to save.

I should reiterate that I'm not personally invested in what the final thumbnail size is other than to say that a full size flattened save inside the xcf would not be my first choice, and one I personally find a waste of space. 

How about this: clearly define a workflow for having a thumbnail and what is their purpose. 

For me, a thumbnails purpose is to quickly give me enough information about the image to decide if further action is desired with that image. It could be as simple as file management (moving things around) or possibly choosing a file for further modification.

By definition this is usually a much smaller version of the image. 

If you need to investigate an image in any greater detail, then open it up in GIMP. 

Users who no longer have GIMP installed is NOT a valid use case scenario in my opinion. Just get GIMP again if you need it.

The full-size view outside of GIMP should be addressed by the other projects, I think. If you embed a full-size flattened version I'll direct all of the complaints on file size to you. :).

(In reply to Pat David from comment #10)
> I should reiterate that I'm not personally invested in what the final
> thumbnail size is other than to say that a full size flattened save inside
> the xcf would not be my first choice, and one I personally find a waste of
> space. 

User choice would be good just for this reason. What is one person's waste of space for one workflow is another person's good use of space for another workflow.

> 
> How about this: clearly define a workflow for having a thumbnail and what is
> their purpose. 

Well, Mitch introduced the term "thumbnail". If he had said "preview" we probably wouldn't be having this conversation. But in point of fact many applications (DAM and image viewers) show a thumbnail and *also* a larger or full-size version of the image. 

> For me, a thumbnails purpose is to quickly give me enough information about
> the image to decide if further action is desired with that image. It could
> be as simple as file management (moving things around) or possibly choosing
> a file for further modification.
> 
> By definition this is usually a much smaller version of the image. 

DigiKam (and gwenview and presumably other KDE applications) could generate a full-size preview for most (not all) 2.8 XCF files. But so far they can't do this for 2.9/2.10 XCF files.

If digiKam/etc could decipher and generate previews directly from the 2.9/2.10 XCF file, there wouldn't need to put an embedded thumbnail/preview in GIMP XCF files, as the software would generate the preview and then make the thumbnail.

> If you need to investigate an image in any greater detail, then open it up
> in GIMP. 

If a user is comparing multiple similar XCF files, opening each XCF file with GIMP is time-consuming and somewhat defeats the purpose of using DAM/Image Viewing software.

> 
> Users who no longer have GIMP installed is NOT a valid use case scenario in
> my opinion. Just get GIMP again if you need it.

The situation I faced with PhotoShop and digiKam wasn't that I couldn't open each PhotoShop file, see what it contained, and then save it using compatibility mode because I did still have access to PhotoShop. The problem was dealing with a bunch of old PSD files, something I put off doing for a long time. To me it wasn't worth the time and effort that would have been required to open all those images. If I could have seen the full-size flattened image (which compatibility mode did make possible), then I could have quickly decided which files to delete and which to keep.

The same considerations apply to GIMP files. It's easy to generate a bunch fo files and then forget what's in the files. Full-size previews will add more to the total file size. But they allow more flexibility to users. Even large "not full-size" previews are more useful than a measly 256px or even 512px preview.

> The full-size view outside of GIMP should be addressed by the other
> projects, I think. 

Well, hopefully this can be done, but again, if the project can generate a full-size preview, there's no need to embed a thumbnail in the XCF file. So far, I haven't found any software, KDE/GTK/otherwise, that allows to view 2.9 XCF files, except for software that knows where GIMP hides thumbnails saved to the user's home folder - maybe Nautilus is the only such software?

> If you embed a full-size flattened version I'll direct
> all of the complaints on file size to you. :).

That's OK! Send 'em on!

Seriously speaking, 256px is too small for all the uses to which various users put previews of images:

* It's too small by far for full use of all the functionality that digiKam offers, including the option for seeing thumbnails up to 512px, the ability to preview the full-size image, and the task of sorting through multiple versions of the same image.

* It's too small for people with not so good vision.

* It's too small for people with large screens viewed from any sort of distance away.

* It's too small for retina displays.

If there is a user choice as to "preview/thumbnail" size, that would be good.

If there is no user choice, I'd suggest 1024 pixels as a good compromise between "too small" and "too big".

Let me reiterate:

Define a clear anticipated workflow for the use of a thumbnail/preview of the file.

The decisions made here should be based on a workflow idea for how the results of this work would be used.  Define and enumerate a clear, concise, and targeted understanding of what these would be used for based on the targeted audience of the project through its vision.

I can say for sure that a full size flattened version in the file is a dumb idea, brought about by attempting to rectify problems either in workflow, or other software.

(In reply to Pat David from comment #12)
> Let me reiterate:
> 
> Define a clear anticipated workflow for the use of a thumbnail/preview of
> the file.

I thought I did that by: 

* explaining how image previews and thumbs are used in digikam - similar considerations apply to other DAM/image-viewing software.

* giving specific reasons why 256px is too small for many users given eyesight/screen-type/size and viewing distance from screen.

> The decisions made here should be based on a workflow idea for how the
> results of this work would be used.  Define and enumerate a clear, concise,
> and targeted understanding of what these would be used for based on the
> targeted audience of the project through its vision.

Please do!

> I can say for sure that a full size flattened version in the file is a dumb
> idea, brought about by attempting to rectify problems either in workflow

That's one person's conclusion but it won't be everyone's conclusion. My own workflow is currently hampered quite to the point of "broken", precisely by not being able to use digiKam to view five year's worth of GIMP 2.9 XCF files.

> , or
> other software.

See http://gimp.1065349.n5.nabble.com/GIMP-2-9-XCF-files-and-digiKam-gnome-file-browsers-etc-td46785.html#a47333, especially Boudewijn's description of how KDE (not just digiKam) "gets" previews and thumbnails.

Before taking this discussion further, the prior question is what purpose embedding a large or small flattened version of an XCF file is supposed to serve: 

Will a GIMP XCF "embedded flattened preview of some as yet unspecified size" take the place of requiring a KIO plugin to generate the thumb? 

Will it take the place of requiring QImageIO to generate the full image view? 

Can KDE KIO/QImageIO be modified to retrieve the embedded preview?

I think this discussion needs input from an actual KDE developer.

As 2.9 layer blending and such has considerably changed over the last five years, if digiKam/KDE has to make it's own preview and thumbnail, only new XCF files going forward will be viewable in KDE apps.
 
Even for 2.8 XCF files, sometimes KDE can't generate a thumb or full-size image and instead digiKam crashes. So if KDE could use an embedded preview, that might solve a lot of problems when viewing XCF files in KDE apps.

(In reply to Elle Stone from comment #13)

> So if KDE could use an embedded preview,
> that might solve a lot of problems when viewing XCF files in KDE apps.

Possibly including "future-proofing" for GIMP 3.0 and beyond.

This isn't KDE-specific anymore.

I would like to propose an alternative to thumbnail (or a complementary solution, having a thumbnail is also a good idea). Couldn't we move out most XCF reading/writing code into a standalone libxcf library?

This lib could be packaged individually by distributions so that XCF files could be read and processed without having to install GIMP nor having to reimplement the format each time. And we would of course also link it in GIMP itself.

I've been thinking about this for quite some time, seeing all these various programs trying to reimplement part of XCF.

Such a library would need to know almost everything about gimp images,
submitting all that (currently internal) code to public (API and ABI)
compatibility issues.

I am *very* reluctant to even consider this.

The original request is actually a duplicate.

*** This bug has been marked as a duplicate of bug 551262 ***