Subject: [Gimp-gui] Improving Export

From: Jehan <[email-masked]>
Date: Mon, 12 Oct 2015 16:57:26 +0200

Hi all,

Some may have heard that I have been working on improving Export lately 
(http://girinstud.io/news/2015/09/improving-the-export-process-in-gimp/), 
and for the ones who met me in LGM, you may even have known that I have 
been thinking about this topic for more than a year.

The basic idea is that our current export dialog is too basic, because 
it has been sharing the same code logics as "save" for too long. But 
while you *save* a work in progress without any loss in higher possible 
quality, you actually *export* a "snapshot" of this work for various 
different reasons (high quality print, small file for the web…). The 
export dialog should show its specificities.

So now we have 2 concepts of Save != Export since GIMP 2.8, result of 
the Save + Export spec 
(http://gui.gimp.org/index.php/Save_%2B_export_specification). And since 
my commits about a month ago, we have finally separate code bases for 
these, allowing us to go further.

I'm thinking that we could include optional modifications of the 
exported images (like resolution, color profile changes, etc.), and also 
that we could have the filetype-specific options in the export dialog 
itself, instead of being managed by the plugins (this of course implies 
an API change for GIMP 3.0 for instance).

The workgroup wiki page:
http://gui.gimp.org/index.php/Export_dialog_workgroup

What are your thoughts?

Jehan

---

From: Jehan <[email-masked]>
Date: Mon, 12 Oct 2015 19:20:04 +0200

Hi,

On 2015-10-12 16:57, Jehan wrote:
> and for the ones who met me in LGM, you may even have known that I
> have been thinking about this topic for more than a year.
> 
> while you *save* a work in progress without any loss in higher
> possible quality, you actually *export* a "snapshot" of this work for
> various different reasons (high quality print, small file for the
> web…). The export dialog should show its specificities.
> 
> (http://gui.gimp.org/index.php/Save_%2B_export_specification). And
> since my commits about a month ago, we have finally separate code
> bases for these, allowing us to go further.
> 
> exported images (like resolution, color profile changes, etc.), and
> also that we could have the filetype-specific options in the export
> dialog itself, instead of being managed by the plugins (this of course
> implies an API change for GIMP 3.0 for instance).
> 
> The workgroup wiki page:

After some discussion on IRC, I updated the wiki page with the various 
ideas, and a wireframe by pippin. Feel free to comment! :-)

Jehan

---

From: Elle Stone <[email-masked]>
Date: Mon, 12 Oct 2015 16:15:05 -0400

> ideas, and a wireframe by pippin. Feel free to comment! :-)

In the proposed export dialog, will there be a place to choose the 
precision for the exported file? For example, when exporting an image 
file from a 32-bit floating point xcf layer stack:

* jpegs can be exported at 8-bit integer
* pngs can be exported as 8-bit or 16-bit integer
* tiffs can be exported as 8-bit integer, 16-bit integer or floating 
point, 32-bit integer or floating point, etc
* I'm not sure what all the export precision options are for OpenEXR 
images, but there's many more than one
* etc for other file formats

As exporting to a lower precision is likely to invoke the dither dialog, 
it would be nice to be able to set global dither preferences, including 
"No, never dither upon changing the precision and don't ever show the 
dither dialog".

In the proposed export dialog, will there be a way to set a default for 
exporting metadata in tiffs and other file formats?

* For example, right now the tiff export dialog has an advanced menu, 
that's closed by default, that defaults to exporting all the metadata 
that's associated with the xcf layer stack.

* There are use cases for exporting all of the metadata, some of the 
metadata, and none of the metadata.

* Currently the user has to click open the advanced dialog and change 
the metadata export settings as desired, and then do it all again the 
next time GIMP is opened.

* It would really be nice to be able to save metadata and other export 
presets, to avoid having to make the same choices every time an image is 
exported from GIMP.

Several suggestions regarding the export dialog were made in an earlier 
thread: 
http://gimp.1065349.n5.nabble.com/Useability-enhancement-request-unified-expanded-file-export-dialog-td44924.html

Elle

---

From: Alexandre Prokoudine <[email-masked]>
Date: Mon, 12 Oct 2015 23:32:49 +0300

On Mon, Oct 12, 2015 at 11:15 PM, Elle Stone
<[email-masked]> wrote:

> * I'm not sure what all the export precision options are for OpenEXR images,
> but there's many more than one

As per spec:

Integers: 8, 16, 32 or 64 bits; unsigned char, short, unsigned short,
int, unsigned int, unsigned long.

Floats: 16, 32 or 64 bits; half, float, double

Alex

---

From: Jehan <[email-masked]>
Date: Tue, 13 Oct 2015 00:07:40 +0200

Hi,

> In the proposed export dialog, will there be a place to choose the

Just making sure this is clear. Workgroups are a public brainstorming of 
what will become GIMP. There is no "proposed" dialog yet, and we can't 
say what "will be". We have barely started discussing this improvement.

> As exporting to a lower precision is likely to invoke the dither
> dialog, it would be nice to be able to set global dither preferences,
> including "No, never dither upon changing the precision and don't ever
> show the dither dialog".

All these are filetype-specific options, and therefore will not be 
discussed in this spec. Filetype-specific options will stay handled as 
filetype handler plugins.

What we "may" change within this spec is how we will handle filetype 
specific options. The current logic is to let plugins fully manage these 
by constructing their own UI. The consequence is that exporting files is 
usually a 2 popup steps: the first (generic) dialog, then a second 
dialog (filetype specific options).
This would be worth improving by having filetype handler plugin only 
advertize their options to GIMP core so that we could dynamically 
construct filetype-specific options within the main dialog.

But the content of these specific options is out of scope from current 
discussion.

> In the proposed export dialog, will there be a way to set a default
> for exporting metadata in tiffs and other file formats?

Metadata on the other hand can indeed maybe be handled partly in the 
spec since they are used across image formats. Well this would have to 
be thought about.

> next time GIMP is opened.

Here the problem is more generic than just metadata: the problem is that 
chosen export options are not kept across GIMP restart. This is 
something I thought about too, though I forgot to add this into the 
wiki.

This said, the "preset" idea is even an advanced version of saving 
option values, as you could keep several (named) sets of option values.

> presets, to avoid having to make the same choices every time an image
> is exported from GIMP.
> 
> Several suggestions regarding the export dialog were made in an
> earlier thread:

I'll read this later. This said, just skimming through the first email, 
I see you are also mixing filetype-specific and generic options. So for 
reminder, this spec will only discuss generic options (working across 
file types) as well as the way to manage specific options (without going 
into their contents).

All supported formats being handled as plugins and not in the core of 
the codebase is — I believe — an important feature since it allows to 
add new format support very easily.

Jehan

> Elle
> _______________________________________________
> gimp-gui-list mailing list
> [email-masked]
> https://mail.gnome.org/mailman/listinfo/gimp-gui-list

---

From: Jehan <[email-masked]>
Date: Tue, 13 Oct 2015 00:12:49 +0200

Hi again,

> ideas, and a wireframe by pippin. Feel free to comment! :-)

There have been a recent feature request about having the open dialog as 
a dock rather than a dialog: 
https://bugzilla.gnome.org/show_bug.cgi?id=756197

I thought this is an interesting idea, which could also be used for the 
export dialog. Not necessary completely removing the use of the dialog, 
since a dock-only export might prove a little tight for formats with 
many options.

This said, this might be quite interesting to be able to keep an export 
dock at hand, especially with a preset feature.

Jehan

---

From: Elle Stone <[email-masked]>
Date: Mon, 12 Oct 2015 18:43:50 -0400

> say what "will be". We have barely started discussing this improvement.

OK, then I'm proposing that there should be a way to choose the 
precision of the exported image, as otherwise the user will have to 
change the precision of the layer stack in order to export the image at 
the desired precision.

> filetype handler plugins.

I'm not sure how the dither dialog is a filetype-specific option. It's a 
rdialog that pops up whenever the user changes precision of the xcf 
file, and there's no way to permanently dismiss it. This is a useability 
issue that affects exporting an image (as well as any other reason a 
user might have for changing precision).

> something I thought about too, though I forgot to add this into the wiki.

Some of the export dialogs do allow to save preferences. The tiff export 
dialog doesn't.

> option values, as you could keep several (named) sets of option values.

It would be nice if users could set up presets, or "metadata templates" 
based on the metadata they really want to export.

For example, when I upload photographic images to the web, first I use 
exiftool to strip out all the metadata, including any embedded sRGB 
profile, and then I use exiftool to embed just copyright information 
metadata, plus a V2 sRGB profile.

When exporting sRGB images for use as part of a web design element, the 
user probably doesn't want to embed an sRGB profile. But maybe they do 
want to embed copyright information, depending on the particular design 
element.

Most users aren't going to resort to using a command line tool for 
removing old metadata and embedding new metadata and maybe a V2 sRGB 
profile. So this seems like a natural fit for user-saved templates that 
could be applied during export.

If this is the wrong place to mention templates for metadata and 
embedded ICC profiles in exported images, my apologies!

> file types) as well as the way to manage specific options (without going

Several people offered a diverse set of suggestions. I haven't reread 
the thread to see what might count as filetype vs generic options. But 
some of the suggestions are already in the wireframe.

Elle

---

From: Jehan <[email-masked]>
Date: Tue, 13 Oct 2015 01:11:04 +0200

Hi,

On 2015-10-13 00:43, Elle Stone wrote:
> change the precision of the layer stack in order to export the image
> at the desired precision.
> 
> I'm not sure how the dither dialog is a filetype-specific option. It's
> a rdialog that pops up whenever the user changes precision of the xcf
> file, and there's no way to permanently dismiss it. This is a
> useability issue that affects exporting an image (as well as any other
> reason a user might have for changing precision).

Yes you are right that this is something which could be thought as a 
generic option. We should think how this could be handled generically.

> Some of the export dialogs do allow to save preferences. The tiff
> export dialog doesn't.

Yes most options are handled per-plugin right now, whereas sometimes 
they could be handled on an upper level. For instance someone was noting 
that some format have a preview on canvas (well jpg has at least), 
whereas this should typically be considered a generic feature.
Saving option preferences is one of these things which should be handled 
by GIMP, so that plugin don't have to deal with the problematic and have 
auto-saving by default.

> It would be nice if users could set up presets, or "metadata
> templates" based on the metadata they really want to export.
> 
> When exporting sRGB images for use as part of a web design element,
> the user probably doesn't want to embed an sRGB profile. But maybe
> they do want to embed copyright information, depending on the
> particular design element.
> 
> profile. So this seems like a natural fit for user-saved templates
> that could be applied during export.
> 

No this is the right place. And clearly metadata is related to export. I 
could indeed imagine there would a way to edit metadata from the export 
dialog without editing the main metadata, and have these export metadata 
saved.

Let's note also that it could be worth opening another workgroup for 
dealing with the main metadata dialog by the way. The current GUI for 
metadata is really minimalist and even quite terrible (not even speaking 
of editing — which is not possible right now — but just the way it 
displays the metadata looks really improvable).
Do not hesitate if you want to open a separate discussion for this 
specific aspect.

Jehan

---

From: Jehan <[email-masked]>
Date: Tue, 13 Oct 2015 14:49:19 +0200

Hi,

On 2015-10-13 06:16, Liam R E Quin wrote:
> On Tue, 13 Oct 2015 00:12:49 +0200
> Jehan <[email-masked]> wrote:
> 
> Inkscape does this - I actually hate it, because (1) it takes up a lot
> of space when i dont' want it, and (2) it doesn't go away when the
> drawing is exported.

I see. Well there are other ways to tell whether an image is exported 
though. There could be a message in the export box for instance saying 
"Last export at 14:45 to /some/path/bla.png". For the space, if the UI 
is well thought, this could also be managed.

Anyway that's a good feedback. It makes some food for thoughts.

> So I go into the folder and check the file is
> there, outside Inkscape. Just as now, in GIMP, to know an image has
> been exported, I click on the [x] on its tab (in single window mode,
> or close its image window) and the dialogue box tells me whether the
> image has been exported.
> 
> 
> My current workflow is to save an image at several sizes - very common
> for Web work, e.g. for "download" and "preview" and "thumbnail"
> versions of an image..
> 
> 1. save archival PNG version (and also XCF if there's more than on 
> elayer)
> 2. scale down
> 3. sharpen (e.g. unsharp mask; the older "sharpen" filter was actually
> slightly better for this for
>    some of my images)

Just a small off-topic remark: is there a bug report about this, and/or 
is it known by Mitch or other devs? If the former algorithm was 
performing better in some condition, this could be of interest and maybe 
should be fixed, no?
Especially if the old filter is meant to disappear in the end.

> 3. file->export brings up file chooser, then options
> 4. experiment with preview and options to minimize file size
> 5. enter quality settings into the JPEG comment field
> 6. OK, export the file
> 7. undo the sharpen
> 8. undo the scale
> 9. gaussian blur
> 10. scale down further
> 11. sharpen; may need to go back to 9 and repeat until OK
> 12 export again
> 13. undo lots,
> 14, gaussian blur more
> 15 scale down to 200 pixel preview
> etc etc
> 
> It's possible to get OK results with nohalo or lohalo scaling instead
> of cubic, and not need to sharpen, but then it can easily take 10
> minutes to scale an image instead of a matter or seconds.
> 
> Its pretty common to sharpen after scaling down. You can't re-open a
> JPEG file and sharpen it afterwards, as (1) you'd lose the benefits of
> the convenient workflow, and (2) it'll sharpen and increase the JPEG
> compression noise, and (3) you'll end up with a much larger file
> because of the increased high-frequency components around the
> compression artifacts. Although you could export to PNG and then
> reopen, I don't see any point - I'd stick with the "scale and undo"
> workflow.
> 
> Hope this helps,

It does. That's a pretty concrete and detailed workflow, the kind that 
many of us have had to do once in a while (of course some more than 
others, like yourself), and which show that the export process can 
definitely be improved!
Actually I think I'll link the feedback in the wiki.

Jehan

> Liam (ankh)

---

From: Liam R E Quin <[email-masked]>
Date: Tue, 13 Oct 2015 00:16:10 -0400

> https://bugzilla.gnome.org/show_bug.cgi?id=756197

Inkscape does this - I actually hate it, because (1) it takes up a lot of space when i dont' want it, and (2) it doesn't go away when the drawing is exported. So I go into the folder and check the file is there, outside Inkscape. Just as now, in GIMP, to know an image has been exported, I click on the [x] on its tab (in single window mode, or close its image window) and the dialogue box tells me whether the image has been exported.

My current workflow is to save an image at several sizes - very common for Web work, e.g. for "download" and "preview" and "thumbnail" versions of an image..

1. save archival PNG version (and also XCF if there's more than on elayer)
2. scale down
3. sharpen (e.g. unsharp mask; the older "sharpen" filter was actually slightly better for this for
   some of my images)
3. file->export brings up file chooser, then options
4. experiment with preview and options to minimize file size
5. enter quality settings into the JPEG comment field
6. OK, export the file
7. undo the sharpen
8. undo the scale
9. gaussian blur
10. scale down further
11. sharpen; may need to go back to 9 and repeat until OK
12 export again
13. undo lots,
14, gaussian blur more
15 scale down to 200 pixel preview
etc etc

It's possible to get OK results with nohalo or lohalo scaling instead of cubic, and not need to sharpen, but then it can easily take 10 minutes to scale an image instead of a matter or seconds.

Its pretty common to sharpen after scaling down. You can't re-open a JPEG file and sharpen it afterwards, as (1) you'd lose the benefits of the convenient workflow, and (2) it'll sharpen and increase the JPEG compression noise, and (3) you'll end up with a much larger file because of the increased high-frequency components around the compression artifacts. Although you could export to PNG and then reopen, I don't see any point - I'd stick with the "scale and undo" workflow.

Hope this helps,

Liam (ankh)

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/