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
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
