scott092707 (forums@gimpusers.com) wrote:

2.8.14 told me that "Opening '/data/scott/Desktop/100_0642&5.xcf' failed: XCF error: unsupported XCF file version 8 encountered" (see screenshot).

Will this always happen, if I try to open a file saved in an earlier-vintage GIMP?

No, this will not always happen, just when you use features that are not available in the older gimp version - e.g. high precision pixel formats.

I hope this helps, Simon

simon@budig.de              http://simon.budig.de/

On 05/12/15 13:17, Simon Budig wrote:

scott092707 (forums@gimpusers.com) wrote:

2.8.14 told me that "Opening '/data/scott/Desktop/100_0642&5.xcf' failed: XCF error: unsupported XCF file version 8 encountered" (see screenshot).

Will this always happen, if I try to open a file saved in an earlier-vintage GIMP?

No, this will not always happen, just when you use features that are not available in the older gimp version - e.g. high precision pixel formats.

Wouldn't it be useful to have a different file extension for the new high-precision contents?

On Sat, Dec 5, 2015 at 5:06 PM, Ofnuts wrote:

No, this will not always happen, just when you use features that are not available in the older gimp version - e.g. high precision pixel formats.

Wouldn't it be useful to have a different file extension for the new high-precision contents?

What's the benefit? Should file extension be changed every time some major change happpens? How many different file extensions for GIMP would you be comfortable with?

Alex

On 05/12/15 15:58, Alexandre Prokoudine wrote:

On Sat, Dec 5, 2015 at 5:06 PM, Ofnuts wrote:

No, this will not always happen, just when you use features that are not
available in the older gimp version - e.g. high precision pixel formats.

Wouldn't it be useful to have a different file extension for the new high-precision contents?

What's the benefit?

Not endlessly explaining to users that there are two different types of XCF. I hate to say this, but Microsoft did it right with the new docx/xlsxl extensions. Granted, upgrading Gimp to the latest version won't be a rip-off so we can expect most people to upgrade quickly, but the transition period can lead to some severely confused people. And there may be tools around (Image viewers for instance) that accept "XCF" but will only support the

Should file extension be changed every time some major change happpens? How many different file extensions for GIMP would you be comfortable with?

One per incompatible change (ie, version N cannot load version N+1).

On 12/05/2015 11:36 AM, Ofnuts wrote:

Wouldn't it be useful to have a different file extension for the new high-precision contents?

What's the benefit?

Not endlessly explaining to users that there are two different types of XCF. [ ... ]

Should file extension be changed every time some major change happpens? How many different file extensions for GIMP would you be comfortable with?

One per incompatible change (ie, version N cannot load version N+1).

Maybe a notice that works like the "tip of the day" in versions of the GIMP that make xcf files that earlier versions can't handle? It could even be the first item in the tip of the day rotation...

Explicitly advising users in advance that their shiny new GIMP installation makes files earlier versions can't open would be Good Thing. A similar notice might be displayed on the gimp.org download page. This might help many users who do collaborative work to avoid potentially costly (lost time, missed deadlines) issues.

:o)

scott092707 (forums@gimpusers.com) wrote:

Will this always happen, if I try to open a file saved in an earlier-vintage GIMP?

Simon Budig writes:

No, this will not always happen, just when you use features that are not available in the older gimp version - e.g. high precision pixel formats.

If I load a JPEG into git master built a few days ago, make no changes and immediately save as XCF, then exit and try to open that XCF in GIMP 2.8, it fails:
"Opening '/tmp/can7795-scale.xcf' failed: XCF error: unsupported XCF file version 8 encountered"

It would be great if the files were incompatible only if you use new features that the old XCF doesn't support, as Simon says; but so far, it seems XCFs saved by 2.9 are never compatible with 2.8.

I've wished many times for a way to save "old XCF" format. I've been using 2.9 for most of my GIMPing, but there are a few images I'd like to be able to share with other people or edit on machines that don't have the libraries needed for 2.9. I try to remember to edit those images only with 2.8, but I forget, and once they've been saved with 2.9 even once they're forever out of reach of 2.8.

...Akkana

El sáb, 05-12-2015 a las 13:00 -0500, Steve Kinney escribió:

On 12/05/2015 11:36 AM, Ofnuts wrote:

Wouldn't it be useful to have a different file extension for the new
high-precision contents?

Speaking strictly from a user perspective, it always sucks when you try to open a file and the program fails to open complaining that it was created with a newer version. It's awful UX. Personally, I would prefer that the program warns me that the file was created with a newer version and some features can be missing and open at least something.

As GIMP is going to take some time to be released, it's probably a better idea to try to keep some two way compatibility for the people who's going to use 2.9 as part of their production pipelines. I know that 2.9.x is a development version and it's not ready yet, but since it has some really attractive features, some people will use it as a complement for GIMP 2.8.x
I'm one of those users. I use GIMP stable mainly for my work, but high bit depth editing is attractive since it allows me to do some things that aren't possible with 8 bpc sRGB. Once GIMP 2.10 is out I will definitely use it, but for now, I'm going to use it only for some tasks, as a complement for the stable version. The XCF version incompatibility is certainly a hurdle.

Gez.

Hi,

On Sat, Dec 5, 2015 at 7:26 PM, Akkana Peck wrote:

scott092707 (forums@gimpusers.com) wrote:

Will this always happen, if I try to open a file saved in an earlier-vintage GIMP?

Simon Budig writes:

No, this will not always happen, just when you use features that are not available in the older gimp version - e.g. high precision pixel formats.

If I load a JPEG into git master built a few days ago, make no changes and immediately save as XCF, then exit and try to open that XCF in GIMP 2.8, it fails:
"Opening '/tmp/can7795-scale.xcf' failed: XCF error: unsupported XCF file version 8 encountered"

We have a new zlib compression, which is much more efficient than the previous RLE compression (like 2 or 3 times smaller files). Yet we are aware that for some people, retro-compatibility is more important than small files. This is why you have a case "Save this XCF file with maximum compatibility" in the save dialog. When you check it, it will save a XCF with the older compression, which can be opened with GIMP 2.8, probably even GIMP 2.6 or older!

BUT jpeg images have metadata, and as you know, GIMP 2.9 has new metadata support. This by itself is a new feature which was not supported on older GIMP. So when you create a XCF from a JPEG made by a camera, the checkbox "Save this XCF file with maximum compatibility" will be grayed-out because anyway, this is not possible to make the file 2.8-compatible if you want metadata support.

Same if you create high precision images.

Same if you use the new overlay mode on layers.

It would be great if the files were incompatible only if you use new features that the old XCF doesn't support, as Simon says; but so far, it seems XCFs saved by 2.9 are never compatible with 2.8.

As explained above, no it is exactly as Simon says. If you create an image from scratch (as a painter or designer for instance), in 8-bit and without overlay layers, you will always have the possibility to check the "compatibility" box if retro-compatibility is very important to you.

But images from photos made by camera (hence with a lot of metadata), nope.

Now, it would be cool if you could get rid of the metadata, for people who don't care about them and prefer retro-compatibility. Unfortunately we don't have metadata editing (hence erasing) support yet. Only reading and saving. We welcome developers interested by the topic and who want to contribute. I believe metadata editing is a much-needed and wanted features by many people. :-)

But for now, until some people comes up and implement this, we can't have the cake and eat it: new features in the XCF format means higher format version. There is no escaping it.

Maybe a good feature could be to have a small text listing exactly the reason(s) why an image cannot be saved in compatibility mode (overlay layer, high bit depth, metadata or a mix of 2 or 3 of these features. The new compression is the only feature which is bypassable and does not block compatibility mode).

Jehan

I've wished many times for a way to save "old XCF" format. I've been using 2.9 for most of my GIMPing, but there are a few images I'd like to be able to share with other people or edit on machines that don't have the libraries needed for 2.9. I try to remember to edit those images only with 2.8, but I forget, and once they've been saved with 2.9 even once they're forever out of reach of 2.8.

...Akkana _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On Mon, 7 Dec 2015 19:42:24 +0100, Jehan Pagès wrote:

Maybe a good feature could be to have a small text listing exactly the reason(s) why an image cannot be saved in compatibility mode (overlay layer, high bit depth, metadata or a mix of 2 or 3 of these features. The new compression is the only feature which is bypassable and does not block compatibility mode).

How about having an option to Export to the old format version?

begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end

Hi,

On Tue, Dec 8, 2015 at 10:17 PM, Jernej Simončič wrote:

On Mon, 7 Dec 2015 19:42:24 +0100, Jehan Pagès wrote:

Maybe a good feature could be to have a small text listing exactly the reason(s) why an image cannot be saved in compatibility mode (overlay layer, high bit depth, metadata or a mix of 2 or 3 of these features. The new compression is the only feature which is bypassable and does not block compatibility mode).

How about having an option to Export to the old format version?

Now wanting to sound sarcastic, but have you read my email? There is such an option and I told about it in the email you answer to. Quoting myself:

This is why you have a case "Save this XCF file with

maximum compatibility" in the save dialog. When you check it, it will save a XCF with the older compression, which can be opened with GIMP 2.8, probably even GIMP 2.6 or older!

But there are some features which are intrinsically impossible to make compatible. In particular, high bit depth or new layer modes. Being "compatible" just means not using the features (and making the file compatible during save only means "losing data and even getting a different render").
Just as there were some features which made some XCF files from GIMP 2.8 incompatible with 2.6 (in particular: using layer groups made your XCF file non openable in 2.6), there are new features in 2.10 which will do the same for 2.8.

Now for the particular issue of metadata, I realized after my email yesterday that they are saved in a way which can make a XCF with metadata still compatible in GIMP 2.8 without losing the metadata on saving (simply they cannot be viewed nor edited in 2.8, but they will still be passed along and viewable/editable when the file is reopened in 2.10). So I made a patch for this on our bug tracker, waiting for Mitch review.

I believe this was the most annoying issue here (at least reading Akkana email).

Jehan

On Tue, 8 Dec 2015 22:53:05 +0100, Jehan Pagès wrote:

Now wanting to sound sarcastic, but have you read my email? There is such an option and I told about it in the email you answer to. Quoting myself:

I've seen that, but what I specifically meant was a File -> Export option that writes XCF compatible with older GIMP versions, possibly losing data in the process (which is why it'd be Export, not Save).

begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end

On Tue, 2015-12-08 at 22:56 +0100, Jernej Simončič wrote:

On Tue, 8 Dec 2015 22:53:05 +0100, Jehan Pagès wrote:

Now wanting to sound sarcastic, but have you read my email? There is
such an option and I told about it in the email you answer to. Quoting myself:

I've seen that, but what I specifically meant was a File -> Export option
that writes XCF compatible with older GIMP versions, possibly losing data
in the process (which is why it'd be Export, not Save).

I keep wondering why we would want that at all.

- as long as we have 2.9, it's unstable and it's their own   fault if people use it

- as soon as we have 2.10, every older version is obsolete,   it's not like one would have to buy 2.10 and must stick   with 2.8 because it's not affordable

So why bother with compat saving at all?

--Mitch

Michael Natterer writes:

On Tue, 2015-12-08 at 22:56 +0100, Jernej Simončič wrote:

I've seen that, but what I specifically meant was a File -> Export option
that writes XCF compatible with older GIMP versions, possibly losing data
in the process (which is why it'd be Export, not Save).

I keep wondering why we would want that at all.

- as soon as we have 2.10, every older version is obsolete,   it's not like one would have to buy 2.10 and must stick   with 2.8 because it's not affordable

So why bother with compat saving at all?

No one has to stick with 2.8 for cost reasons. But most people, at least on Linux, will have to upgrade their OS to get all the libraries needed to run the new GIMP. Historically, it can take six months or longer after a release before most Linux users can run the new GIMP version, and a few users (on "stable" releases) may wait a lot longer than that.

...Akkana

Hi,

On Wed, Dec 9, 2015 at 9:29 PM, Akkana Peck wrote:

Michael Natterer writes:

On Tue, 2015-12-08 at 22:56 +0100, Jernej Simončič wrote:

I've seen that, but what I specifically meant was a File -> Export option
that writes XCF compatible with older GIMP versions, possibly losing data
in the process (which is why it'd be Export, not Save).

I keep wondering why we would want that at all.

- as soon as we have 2.10, every older version is obsolete, it's not like one would have to buy 2.10 and must stick with 2.8 because it's not affordable

So why bother with compat saving at all?

No one has to stick with 2.8 for cost reasons. But most people, at least on Linux, will have to upgrade their OS to get all the libraries needed to run the new GIMP. Historically, it can take six months or longer after a release before most Linux users can run the new GIMP version, and a few users (on "stable" releases) may wait a lot longer than that.

Yes but the question still remains: if you want to share a XCF, this is usually for team working (or similar reasons involving others wanting to edit your work). Then if you used a new feature, how do you pass your work to someone with another version?

For instance if you were using high bit depth, then if you "save" without high bith depth in order to have a 2.8-compatible XCF, the person you shared with simply has a different image. Then if this persons edits this image, and sends it back to you, then what? You now have a 8-bit version. If that is not a problem, why bother from the start with high bit depth? Oppositely if high bit depth is too important to you for even considering losing it, there is simply no other solution: everyone must have a recent version of GIMP able to process high bit depth.

I took this feature as an example, but that is also true for any other feature which would require an update in the XCF format.

Jehan

P.S.: maybe we could have an extension standard within XCF which could allow older versions to load newer XCF files using unknown feature and displaying warnings but still loading a "partly broken" file. This could be an interesting update, why not. But right now, this does not exist. And it would not be possible for every kind of feature (once again, the high bit depth changes the image data in too much a deep way to make this easy).

P.P.S.: this said, I agree with Mitch that there are very few (good) reasons to keep an old version of GIMP. And I don't think we should encourage this. As for the package management systems which are indeed slow to update on many Linux distributions, I have good hope towards the xdg-app project which would make such a worry a thing of the past.

...Akkana
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list