Re: [Gimp-developer] [PATCH] OpenRaster: optimize PNG saving

[Jon Nordby]

On Sat, Mar 6, 2010 at 3:30 PM, Martin Nordholts  wrote:

> On 02/27/2010 03:14 PM, Jon Nordby wrote:
> > Sets lower compression and disables interlacing.
> > On a 5 layer image of 4500x6000px this gives an order of magnitude better
> > save-times, with 50% increase in file size.
>
> Hi Jon
>
> Sorry for the late follow-up and thanks for maintaining the ORA plug-in.
>
> 50% increase in file size is pretty significant, maybe the compression
> ratio should be exposed in a UI?
>
First some absolute numbers (rough measurements) so we don't get lost in
relative figures.
Saving said image on a 2Ghz core2duo with enough memory too keep it from
swapping yields:
xcf - 150MB - under 10 seconds
xcf.gz - 65MB - about 23 seconds
ora, before patch (maximum compression) - 48MB - about 7 minutes
ora, after patch - 63MB - about 30 seconds

Do you really think there it is a big point to introduce a UI for selecting
compression?
In my experience, the predominant usecase for OpenRaster seems to be for
interchange between different applications when working locally. And for
that I don't see the point.


> > @@ -85,7 +85,7 @@ def save_ora(img, drawable, filename, raw_filename):
> >
> > def store_layer(img, drawable, path):
> > tmp = os.path.join(tempdir, 'tmp.png')
> > - pdb['file-png-save-defaults'](img, drawable, tmp, 'tmp.png')
> > + pdb['file-png-save'](img, drawable, tmp, 'tmp.png', 0, 2, 1, 1, 1, 1,
> 1)
>
> It would be nice to make 0, 2, 1, 1, 1, 1, 1 immediately interpretable,
> for example by commenting or using local variables like so:
>
>   embed_profile = 1
>   function(1, # save_comment
>embed_profile)
>
You are right. Attached patch addresses this.

-- 
Regards Jon Nordby - www.jonnor.com


0001-OpenRaster-optimize-PNG-saving-2.patch
Description: Binary data
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Adding ability to reverse curves dialog

[Liam R E Quin]

On Thu, 2010-03-11 at 18:40 +0100, Martin Nordholts wrote:
[...]
> By knowing that it works on buffers with ink density and not light 
> intensity. So how would GIMP know that? There are many heuristics that 
> could be used:
> 
> * Was the buffer created with Decompose?

It's common to decompose even to cmyk (especially when working
with scanned images) and this does not mean that "curves"
should suddenly behave differently, and neither does it mean
that one is working with "ink".  E.g. I sometimes do this to
compensate for registration problems that happened when the
image was printed 100 years ago, e.g. by moving the Y layer.
(I could really do with a View filter that showed the recomposed
result, or maybe a layer mode, so that with all layers shown I
got the proper colour appearance)

Either curve-ui-inversion should be under user control with a flip
button, or not happen, I think.  Curves going backwards when I
switch windows isn't a nice concept.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org www.advogato.org

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer