Re: [Gimp-developer] need help with bug #464466 (downscaling quality)

2008-08-04 Thread gg
On Fri, 01 Aug 2008 13:51:02 +0200, David Gowers [EMAIL PROTECTED] wrote:

  Pixel art ('block graphics'?) is a
 pathological case for most scaling algorithyms, and no algorithym old
 or new performed very well on upscaling image #8.
 David


yes, this is a good test for scaling alorithms. I had not really  
apreciated the nature of this image since, although pixel art, it does  
have predominantly degraded edges so it is not quite the sort of block  
graphic I was refering to. However, picking out some specific areas, it  
does give some good information on the merits of different algorithms for  
this kind of image.

Viewing the comparitive for 133% at 200% (in Opera) there is a noticable  
difference between cubic and lanczos.
http://svenfoo.org/scaletest/133Z8g.png
http://svenfoo.org/scaletest/133C8g.png

opening these two in adjacent tabs in opera and flipping allows direct  
comparison. This difference is quite marked.

Comparing directly to the original at 266% with scaled image at 200% there  
is an impressive restoration of detail lost to pixelisation in the orginal.

The eyebrow, hair and eye are well enhanced as it the hand on the blue  
figure. The staircasing on the knee and thigh of the yellow figure are  
also well smoothed out, though not removed completely.

All parts of this image seem to have been noticably enhanced , I think  
it's a good demonstration of the lanczos code.

Although downscaling is probably the more critical test (and the case that  
was needing most improvement) it may be informative to add another  
enlargement to some oddball ratio (say 3.14159) to see how the detail  
comes out when the result is several times bigger.

BTW , has this code been ported to the rotation operation? IIRC, that was  
a separte file that closely duplicated the scaling code. Maybe this would  
be a good point to unify the two.

In any case I'm very pleased to see the lanczos results on this image.  
Very impressive.

regards.



-- 

   .*.
   /V\
  (/ \)
  (   )
  ^^_^^
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Po-files in SVN have a strange problem

2008-08-04 Thread David Gowers
Hello,

As I was working on Esperanto translation for gimp, I noticed that it
(eo.po).. and the following .po files (in /po/ directory),
 have a strange problem with a message.

pl
fr
ru
ja
lt
oc


One or two messages (the english part) refer to 'Colorsize' where they
should refer to 'Colorize'
(as in 'save colorize settings' and 'export colorize settings').

I assume this was caused by typos in the source code, later corrected.
However, when I ran an update, this message was not removed or
replaced by a correct one.. or even left alone while the correct
message was added.
So, perhaps these files need to be manually changed to correct the
message. That's what I did for eo.po (in my local copy)

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


[Gimp-developer] seeking thoughts on a crash that I caused, and more general question about message passing

2008-08-04 Thread David Merrill
Hello all,
I am playing around with interfacing some custom hardware that I've built
for my PhD to the GIMP. I spent some time yesterday learning how to add
popup menus to the UI, so that I could right-click a slider (such as the
Cyan / Magenta / Yellow ones in the Color Balance dialog), and bind the
slider to data from my input device on-the-fly. I got the popup menu to pop
and show the menu entries that I have identified, but after popping the
menus a few times, GIMP always crashes with this message:

(gimp-2.4:23363): Gtk-CRITICAL **: gtk_window_set_accept_focus: assertion
`GTK_IS_WINDOW (window)' failed
Bus error

Does anyone know how my popup menus caused that, and how I can fix it?

The more general question that I have is the following: If I want to route
control messages to and from a Python interpreter that I instantiate in the
GIMP, what would be the most elegant way to run this interpreter and to
route messages? (this is for dynamically controlling the UI - for instance,
to make my hardware control the aforementioned sliders, so I don't think I
can use the same Python architecture that does plugins). Is there a general
message-passing system that I could hook into? Where should I look, to get
started?

thanks in advance!
-David Merrill
-- 
MIT Media Lab
[EMAIL PROTECTED]
http://web.media.mit.edu/~dmerrill/ http://web.media.mit.edu/%7Edmerrill/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Windows - Image display actions potential improvement

2008-08-04 Thread David Gowers
Hello,

I just noticed a usability issue with the 'Windows' actions related to
image displays in SVN... They seem to be attached to specific
displays, rather than to the Nth display out of the current displays.

Currently, we can switch quickly between some active images by using
dynamic keyboard shortcuts and assigning keys (I like '234567' -- a
number key for each of 6 open images) to them as we open them. We can
also quickly switch between alternate views of an image
(eg 100% with selection, layer borders, guides and rulers visible; or
'final rendering size' (50%) without anything but the image visible.
This is quite powerful (try it out!).
However.. any keyboard shortcuts assigned only last until you close
that image -- because each display number only gets generated once
each GIMP session (they are generated sequentially starting from 1).
This is why the usage pattern above requires you to use Dynamic
Keyboard Shortcuts and assign shortcuts as images are loaded.

My proposal is to have these actions index the available image
displays sorted by their display ID -- this amounts to, if you have
keys 123456789 assigned as shortcuts for the 1st .. 9th display, and 9
displays open, pressing 1 will raise the oldest display, pressing 9
will raise the newest. If you close some, 8 or 7 could end up being
the shortcut for the newest display

I believe that both the current code and the proposed amendment are
somewhat surprising : the former because shortcut assignments get
'lost', the latter because shortcuts become assigned to different
images when an image is removed from the middle.
I am sure that my proposed amendment is both less surprising, and a
usability enhancement that anyone who works with more than a few
images at once will appreciate.

I plan to make a patch to try this within a week.


As for why I sent this here, I'm interested to know:

Is there a reason for the current behaviour?

Are there better approaches? (i'm thinking here of GIMP-GAP .. when
you're using it, display IDs get very high quickly, because
each time you switch frames, the display number is incremented. Thus,
my proposal could be a little more surprising to GAP users, because
changing the frame you're editing will bump an animation so it becomes
the 'newest' image.)


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


Re: [Gimp-developer] seeking thoughts on a crash that I caused, and more general question about message passing

2008-08-04 Thread Sven Neumann
Hi,

On Mon, 2008-08-04 at 10:12 -0400, David Merrill wrote:

 The more general question that I have is the following: If I want to
 route control messages to and from a Python interpreter that I
 instantiate in the GIMP, what would be the most elegant way to run
 this interpreter and to route messages? (this is for dynamically
 controlling the UI - for instance, to make my hardware control the
 aforementioned sliders, so I don't think I can use the same Python
 architecture that does plugins). Is there a general message-passing
 system that I could hook into? Where should I look, to get started?

Since you want to control the GUI, you probably want to look at the
accessibility framework of GTK+. There are Python bindings for this, for
example dogtail (http://people.redhat.com/zcerza/dogtail/).

Since this is not at all GIMP related, but purely a GTK+ question,
perhaps you want to ask further questions about this on the a11y mailing
lists.


Sven



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


Re: [Gimp-developer] Po-files in SVN have a strange problem

2008-08-04 Thread Sven Neumann
Hi,

On Mon, 2008-08-04 at 23:25 +0930, David Gowers wrote:

 One or two messages (the english part) refer to 'Colorsize' where they
 should refer to 'Colorize'
 (as in 'save colorize settings' and 'export colorize settings').
 
 I assume this was caused by typos in the source code, later corrected.

That is correct.

 However, when I ran an update, this message was not removed or
 replaced by a correct one.. or even left alone while the correct
 message was added.

How exactly do you update the po files?


Sven


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


Re: [Gimp-developer] need help with bug #464466 (downscaling quality)

2008-08-04 Thread Sven Neumann
Hi,

On Fri, 2008-08-01 at 17:22 -0400, Liam R E Quin wrote:

 So far it feels noticeably slower on mediumsized or large
 images (e.g. a 13899x8497-pixel 2400dpi grayscale scan,
 which Gimp reports as 230MBytes) but the results are
 outstandingly better.

Since the test results are looking good, I think we should commit the
changes then so that they get more testing. Does anyone disagree with
this? Otherwise I will commit the changes later this week.


Sven


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


Re: [Gimp-developer] Po-files in SVN have a strange problem

2008-08-04 Thread David Gowers
Hi,

On Tue, Aug 5, 2008 at 5:06 AM, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,

 On Mon, 2008-08-04 at 23:25 +0930, David Gowers wrote:

 One or two messages (the english part) refer to 'Colorsize' where they
 should refer to 'Colorize'
 (as in 'save colorize settings' and 'export colorize settings').

 I assume this was caused by typos in the source code, later corrected.

 That is correct.

 However, when I ran an update, this message was not removed or
 replaced by a correct one.. or even left alone while the correct
 message was added.


 How exactly do you update the po files?

../intltool-update eo

However, when I run an update on any of the other .po's, it works fine
(no 'Colorsize' message any more, 'Colorize'). Strange.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer