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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]