Re: [Gimp-developer] GIMP 2.8 Feature Request (2)

[Jay Smith <jay JaySmith com>]

On 01/04/2012 12:22 AM, Martin Nordholts wrote:

<snipped other stuff>

> If you rarely use the XCF format you are not part of the target user
> group. The separation of save and export is for users that do complex
> compositions in XCF and export every now and then. For those users,
> the way it works now makes sense. That an image previously was
> considered to be "saved" as PNG was misleading, inaccurate and
> confusing. No non-trivial composition has ever been "saved" in a PNG
> file. Not to mention the metric tonne of popup dialogs you had to wade
> through to "save" in PNG.

<snipped other stuff>

> / Martin


Oh my!

Please clarify so that I can understand if I am "supposed to" stop using 
Gimp and find something else going forward (because Gimp will be 
narrowly focused on one "target user group").

I am not in the "target user group".  Where does Martin suggest I go? 
(Wait, don't answer that!)

I read Martin's statement as saying that Gimp is NOT intended for 
production workflows outside of a narrow definition, that being "users 
that do complex compositions in XCF and export every now and then."

Our workflow is:  Using VueScan Professional (independent of Gimp) to 
scan a high volume of TIFF images.  Open each image in Gimp to tweak 
color, sharpness, rotation, and crop to desired size.  Save as TIFF and 
close.  (Downline we use our own scripts and ImageMagick to batch create 
several sizes of JPEGs for web use; the TIFFs are also used for print 
output and are archived as TIFFs.)

It seems to me that I am being told that a workflow such as ours is 
perhaps "too pedestrian" and "not artistic enough" to be using Gimp. 
Yet, it is the only open source program that we have found that offers 
the quality and features we need to _productively_ do the tasks we do.

I comprehend the "stay in XCF" model and don't have a problem with it. 
I just feel that the swing in saving/exporting concepts was too extreme 
and did not take the opportunity to combine the operations in such a way 
that is logical, useful, and work-saving.  I have not retained the list 
messages from the time that it was discussed and I am too lazy to go 
looking for them, but now (and at that time) I fail to understand what 
was thought to be "broken" and needed fixing.

Not having seen the new model (I am in production, not development; 
there is no time or capability to be examining and testing non-stable 
versions), it sounds like it is going to create a lot more work for us 
and create a LOT of trash files.  We tend to "save" a lot during the 
editing process and if that is going to create XCF files (since we 
started by opening TIFF files), then I am going to have to run a nightly 
housekeeping script to delete all XCF files in the working directory 
structure.

My way of thinking about the appropriate save/export process is:

a) If an image has been created anew (and not opened), then the save 
should automatically to save as XCF unless the user specifies a 
different extent (such as .png or .tif or whatever).  If a different 
extent has been specified, then see 'b'.

b) If an image has been opened, using a non-native extent (i.e. anything 
other than XCF) OR is being saved to a non-native extent (from 'a' 
above), then the save/export test that should be applied is whether or 
not the desired-save/export format results in data loss (due to the 
capabilities of the target format/extent).  If it does result in data 
loss, then the operation automatically becomes a "Save As" (i.e. 
"Export") AND the currently open image remains open in XCF but has not 
been saved (this is a bit of a problem; not sure what to do about that 
unless it is ALSO saved silently alongside the other format).  If the 
operation does not result in data loss, then the operation is allowed to 
proceed to automatically save to the desired format AND the currently 
open image remains open but it has now been saved.

If this process is going to be made a lot more complicated for workflows 
like ours, then I hope that there will eventually be an optional 
mechanism to override the save/export process based on input and output 
file formats.

Jay