Nabble - Gimp Developer

Search-based Menu Browsing GSoC project

2008-07-24T18:05:27Z

I'm really interested in this particular SoC project, I think it has
the potential to greatly improve GIMP user workflow, and it's one of
two that are not in SVN as a branch (so progress cannot be seen
directly during the SoC). Zhang Junbo posted recently (
http://www.mail-archive.com/gegl-developer@.../msg00426.html
) about the progress of his project relating to frequency domain GEGL
operations. So I was curious, Evan, Michael, could you spare a little
time to comment on the state of this project?
Even if it's just two words 'Going well' :)

Thanks,

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

Re: Getting all single bounds of multiple selections

2008-07-24T12:21:02Z

Hi,

On Wed, 2008-07-23 at 10:15 +0200, Eckhard M. Jäger wrote:

> I'd like to create the plugin with Python, but i'm not sure if it is
> possible getting all single bounds
> when you have multiple selection.

There is only one selection per image. Please realize that the selection
is a grayscale mask. So what you call "multiple selections" are several
disconnected areas on the selection mask.

Note that you can access the selection mask as a drawable. That should
give you all the information you need.

Sven

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

Re: metadata and JPEG - plans and current status

2008-07-23T07:51:44Z

On Wed, 23 Jul 2008 11:20:41 +0200, Roman Joost <romanofski@...> wrote:
> On Tue, Jul 22, 2008 at 04:50:41PM +0200, Raphaël Quinet wrote:
> > [...]
> > Currently, the metadata tree is only available inside the metadata
> > editor, which is implemented as a plug-in. This results in several
> > round-trips via the PDB whenever something must be updated.
[...]
> In my unexperienced point of view, it looks like this should be
> clarified first, before I try to improve the current metadata editor.
> IMHO your last point seems to be the way to go, all other attempts like
> the first one seems to be totally inefficient and error-prune.

Yes, this is also my point of view. The best way to go is to have the
metadata tree available in the core with some PDB calls allowing plug-ins
to get/set data, and also have a "libgimp-metadata" library that can be
used by the file plug-ins for performing tasks such as converting between
Exif and XMP. The editor itself could still be a plug-in, but the
lower-level parts of metadata handling would be included in the library
and another part of it would be in the GIMP core.

To recap, the three scenarios are:
1) metadata editor/viewer + metadata format converter + storage are all
done by a plug-in (current situation);
2) metadata editor/viewer + metadata format converter done by a plug-in,
but storage handled in GIMP core;
3) metadata editor/viewer done by a plug-in, metadata format conversions
in a GIMP metadata library, and storage handled in GIMP core.
In the longer term, we can also think about a scenario 4 in which parts
of the metadata viewer/editor could be handled by the core, but that is
not for the short term anyway.

Although I think that it makes a lot of sense to have the metadata
tree inside the core as in scenario 3, Sven seems to disagree so I
would like to have his opinion before deciding how to proceed.

> > So contrary to what I originally planned, I think that the code for
> > converting to/from Exif should be based on that library. This will
> > also make our code smaller and easier to maintain.
> My current plan was to provide a read-only view of the currently stored
> metadata inkl. a button to update the view. This included the conversion
> from Exif to XMP. Currently from my point of view - correct me if I'm
> wrong - the conversation will be called from the imagefile plugin (e.g.
> jpeg-load), after the Exif data is attached as a parasite. The metadata
> exif-decode procedure will convert the Exif data to XMP than, to be able
> to display it as XMP data in the metadata browser.

I think that you got it right. :-) In scenario 1 above, when a file is
loaded the Exif block should be converted to XMP immediately (or more
precisely, it should be converted to a metadata tree, which happens to be
serialized as XMP) and then the metadata parasite is attached to the image.
Later, when the user starts the metadata editor or viewer, the parasite is
retrieved from the image and decoded into a metadata tree that can be
displayed to the user.

Note that in scenarios 2 and 3, it would not be necessary to convert the
metadata tree into XMP and store it in a parasite, because that tree would
be managed by the core. The metadata viewer would only have to retrieve
the relevant elements for display or editing. In fact, in scenarios 2 and
3 the metadata viewer/editor would not have to care about the XMP syntax:
it would only need to know the name and data type of the things that it
wants to display.

> Now after the pros and cons about handling metadata is clarified by your
> mail, how different do we set our priorities to move forward for this
> editor and the metadata management? I think we should setup a roadmap
> first, setup tasks afterwards and start implementing them.

Well, the thing that could change the plans significantly is a decision
about whether or not we integrate the metadata tree inside the core. And
I would like to get Sven's comments about that.

If we start with scenario 2 (for example), then it should not be too hard
to switch to scenario 3 later. However, if we start with 1, then it is
not easy to migrate to 2 or 3 later. Most of the new code would have to
be rewritten differently.

-Raphaël
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: metadata and JPEG - plans and current status

2008-07-23T02:20:41Z

Hi Raphaël,

On Tue, Jul 22, 2008 at 04:50:41PM +0200, Raphaël Quinet wrote:

> Since Roman has offered to improve the metadata handling in GIMP, Sven
> asked me to document what my plans were for the metadata editor and the
> JPEG plug-in. Well, these plans are best summarized in the mail that I
> sent last year:
>
> [...] plans
>
> Maybe a few points from the first message (2.6 roadmap) should be
> clarified a bit. In that message, I wrote:
> [...]

Thanks for clearing this up a bit. This makes the metadata browser far

more complex than I intentionally thought.

> [...]
>
> Currently, the metadata tree is only available inside the metadata
> editor, which is implemented as a plug-in. This results in several
> round-trips via the PDB whenever something must be updated. For
> example, assuming that Exif would now be handled correctly, the
> current implementation would lead to the following scenario when a
> JPEG image is saved:
>
> [...] tremendous amount of calls
>
> And here is what would happen if the metadata tree could be managed by
> the GIMP core, but we still assume that the conversion to/from Exif is
> done by an external plug-in:
>
> [...] less tremendous amount of calls
>
> Furthermore, here is what would happen if the metadata tree could be
> managed by the GIMP core and some common metadata operations (such as
> the conversion to/from Exif) would be in a "libgimp-metadata" library
> linked directly with the file plug-ins that need it:
>
> [...] less, less amount of calls
>
> Sorry for the long details, but using an example like this is probably
> the best way to explain why it would make sense to have some parts of
> the metadata handling performed by a library, and why it would be
> better if the metadata tree could be managed by the GIMP core instead
> of being constantly converted to/from XMP and stored in a parasite.

In my unexperienced point of view, it looks like this should be

clarified first, before I try to improve the current metadata editor.
IMHO your last point seems to be the way to go, all other attempts like
the first one seems to be totally inefficient and error-prune.

> In my message from last year, I also wrote:
> > + convert EXIF to XMP
> > + convert XMP to EXIF
>
> The initial goal of the code that I started writing (and never finished)
> for the conversion to/from Exif was to get rid of the dependency on
> libexif. That library had caused several severe stability problems in
> the past and most developers (including myself) wanted to replace it by
> some code that was more stable.
>
> [...]
> So contrary to what I originally planned, I think that the code for
> converting to/from Exif should be based on that library. This will
> also make our code smaller and easier to maintain.

My current plan was to provide a read-only view of the currently stored

metadata inkl. a button to update the view. This included the conversion
from Exif to XMP. Currently from my point of view - correct me if I'm
wrong - the conversation will be called from the imagefile plugin (e.g.
jpeg-load), after the Exif data is attached as a parasite. The metadata
exif-decode procedure will convert the Exif data to XMP than, to be able
to display it as XMP data in the metadata browser.

Now after the pros and cons about handling metadata is clarified by your
mail, how different do we set our priorities to move forward for this
editor and the metadata management? I think we should setup a roadmap
first, setup tasks afterwards and start implementing them.

Cheers,
--
Roman Joost
www: http://www.romanofski.de
email: romanofski@...

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

signature.asc (196 bytes) Download Attachment

Getting all single bounds of multiple selections

2008-07-23T01:15:34Z

Hello,

i'm thinking about a better slicing plugin based on a addition layer with color informations.
I'd like to create the plugin with Python, but i'm not sure if it is possible getting all single bounds
when you have multiple selection.

Is it possible? The function active_layer.mask_bounds gives only the overall bounds back :(

Thanks.


___/\_______________________________________________________________________

Ich darf nicht angeben.

|\/\/\/| 
|      |        Bart.
| (O)(O)        bart@...
C      _) 
|   ,_/         Linux for Designers - http://my.opera.com/area42/blog/
|   /           SweeTS delicious Typo3 development - http://typo3.area42.de/
/   \

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

Karamba!
Bart.

Linux for Designers - http://my.opera.com/area42/blog/

metadata and JPEG - plans and current status

2008-07-22T07:50:41Z

Since Roman has offered to improve the metadata handling in GIMP, Sven
asked me to document what my plans were for the metadata editor and the
JPEG plug-in. Well, these plans are best summarized in the mail that I
sent last year:

http://lists.xcf.berkeley.edu/lists/gimp-developer/2007-November/018992.html
http://article.gmane.org/gmane.comp.video.gimp.devel/12503/

Basically, every single line of that message is still relevant today.
So I will not quote the whole message again, but I encourage those who
are interested in metadata to read it entirely.

This follow-up message may also be interesting, regarding which Exif
tags should be updated automatically by GIMP and why GIMP should never
ask the user if an image should be rotated automatically or not:

http://lists.xcf.berkeley.edu/lists/gimp-developer/2007-November/019100.html
http://article.gmane.org/gmane.comp.video.gimp.devel/12610/

That's about it for the plans. You should stop reading now if you
are not interested in the details. :-)

---------- scary details below this line ----------

Maybe a few points from the first message (2.6 roadmap) should be
clarified a bit. In that message, I wrote:
> + migrate some parts of the metadata core to a library that can be
> used by the main app. as well as some plug-ins

Currently, the metadata is stored in an XMP packet inside a GIMP
parasite attached to the image. While XMP is a good format for
storage in files, it is not ideal for manipulation (updates and
queries). It would be better it the metadata tree could remain in
memory while the image is open, instead of being converted to/from XMP
all the time. Also, by having this tree attached to the image and
accessible directly by the core for updates and queries, it would be
possible to have the metadata updated in real-time whenever the image
is modified by some tools or plug-ins. This would allow some of the
metadata to be displayed in the image info window, or maybe in the
status bar of the image (more and more programs are doing that).

Currently, the metadata tree is only available inside the metadata
editor, which is implemented as a plug-in. This results in several
round-trips via the PDB whenever something must be updated. For
example, assuming that Exif would now be handled correctly, the
current implementation would lead to the following scenario when a
JPEG image is saved:

- the JPEG plug-in calls "plug-in-metadata-set" to update some metadata
- this is passed to GIMP
- GIMP starts the metadata editor plug-in
- the metadata editor asks GIMP to get the parasite attached to the image
- the parasite (XMP) is parsed and stored in a tree
- the tree is updated according to what was requested
- the tree is encoded into a parasite (XMP)
- the metadata editor asks GIMP to attach the parasite to the image,
then it exits
- (if there is some window currently displaying the metadata associated
with that image, it is *not* updated)
- the JPEG plug-in is informed that the operation was successful
- the JPEG plug-in calls "plug-in-metadata-encode-exif" in order to get
an Exif block from the updated metadata
- this is passed to GIMP
- GIMP starts the metadata editor plug-in again
- the metadata editor asks GIMP to get the parasite attached to the image
- the parasite (XMP) is parsed and stored in a tree
- the metadata editor updates some metadata that must be updated when an
image is saved
- the updated tree is encoded into a parasite (XMP)
- the metadata editor asks GIMP to attach the updated parasite
- (if there is some window currently displaying the metadata associated
with that image, it is *not* updated)
- the contents of the tree are encoded in Exif
- the metadata editor returns an array with the Exif block and exits
- GIMP returns the array to the JPEG plug-in
- the JPEG plug-in can now save the file with the Exif block, then exit
- (if there is some window currently displaying the metadata associated
with that image, the user must remember to refresh the view)

And here is what would happen if the metadata tree could be managed by
the GIMP core, but we still assume that the conversion to/from Exif is
done by an external plug-in:

- the JPEG plug-in calls "gimp-metadata-set" to update some metadata
- this is passed to GIMP, which updates the metadata attached to the
image
- (if there is some window currently displaying the metadata associated
with that image, it *will be* updated)
- the JPEG plug-in is informed that the operation was successful
- the JPEG plug-in calls "gimp-metadata-encode-exif" in order to get an
Exif block from the updated metadata
- GIMP updates some metadata that must be updated when an image is saved
- (if there is some window currently displaying the metadata associated
with that image, it *will be* updated)
- GIMP starts the metadata editor plug-in
- the metadata editor makes several calls to "gimp-metadata-get" in order
to retrieve the parts of the metadata that are relevant for Exif
- GIMP returns the requested data (from its internal tree)
- the metadata editor encodes that information in an Exif block
- the metadata editor returns an array with the Exif block and exits
- GIMP returns the array to the JPEG plug-in
- the JPEG plug-in can now save the file with the Exif block, then exit

Furthermore, here is what would happen if the metadata tree could be
managed by the GIMP core and some common metadata operations (such as
the conversion to/from Exif) would be in a "libgimp-metadata" library
linked directly with the file plug-ins that need it:

- the JPEG plug-in calls "gimp-metadata-set" to update some metadata
- this is passed to GIMP, which updates the metadata attached to the
image
- (if there is some window currently displaying the metadata associated
with that image, it *will be* updated)
- the JPEG plug-in is informed that the operation was successful
- the JPEG plug-in calls "gimp-update-metadata-for-save" in order tell
GIMP that the image is about to be saved
- GIMP updates some metadata that must be updated when an image is saved
- (if there is some window currently displaying the metadata associated
with that image, it *will be* updated)
- the JPEG plug-in makes several calls to "gimp-metadata-get" in order to
retrieve the parts of the updated metadata that are relevant for Exif
- the JPEG plug-in calls the library functions for encoding that metadata
into an Exif block (the previous step could even be performed by the
library functions so that the JPEG plug-in would not have to care).
- the JPEG plug-in can now save the file with the Exif block, then exit

Sorry for the long details, but using an example like this is probably
the best way to explain why it would make sense to have some parts of
the metadata handling performed by a library, and why it would be
better if the metadata tree could be managed by the GIMP core instead
of being constantly converted to/from XMP and stored in a parasite.

In my message from last year, I also wrote:
> + convert EXIF to XMP
> + convert XMP to EXIF

The initial goal of the code that I started writing (and never finished)
for the conversion to/from Exif was to get rid of the dependency on
libexif. That library had caused several severe stability problems in
the past and most developers (including myself) wanted to replace it by
some code that was more stable.

However, the known bugs in libexif have now been fixed (some updates have
not been released yet, but that's another issue) and after studying how
some people (and the programs they use) are using the Exif data, I am now
convinced that preserving the Exif MakerNotes is very important. This is
the trickiest part of Exif and this is where most of the time was spent
in libexif or other libraries (exiv2, etc.). Since parsing and updating
MakerNotes is a difficult task, I think that it is better to leave that
job to libexif instead of re-inventing the wheel. So contrary to what I
originally planned, I think that the code for converting to/from Exif
should be based on that library. This will also make our code smaller
and easier to maintain.

-Raphaël
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: Window resize

2008-07-21T10:03:57Z

Hi,

On Sun, 2008-07-20 at 08:17 -0700, Bill Skaggs wrote:

> Um, GtkWrapBox is part of Gimp, not GTK+, in spite of its name. (I have
> no doubt that Sven knows that, and was reacting without having closely
> read the question.)

I've read the question and I came to the conclusion that it appears not
related to the development of GIMP and that it would be much more
on-topic (and more likely to be answered) on gtk-list or
gtk-app-devel-list.

Sven

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

Re: Gimp default brush set contest

2008-07-20T11:35:27Z

Hi!

My nome is Filipe.

Valerie and I have done in recent weeks a package of paintbrushes and stripped down to the GIMP. We hope that you, developers take a look at it.
He was evaluated by some GIMP artists and approved. :)

I posted it on DeviantArt using the "Creative Commons License Attribution-Share Alike 3.0 Unported". We can change the license if its needed.

Link: http://filsd.deviantart.com/art/GIMP-possible-Defaut-set-92263636

We really hope you Devs and users take a look. Would be great if the GIMP had such Brushes.

Thanks.

--
Filipe Soares Dilly
dilly.carbonmade.com/

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

Re: Enhancement request - Use alpha channel for non-transparent information

2008-07-20T10:46:47Z

That sounds really good Joao, I was thinking of a "use layer as alpha"
overriding

option for the TGA save dialog(which eliminates the layer being used in the final image
other than to serve as the alpha channel, of course).

I'm also thinking of an "extract alpha to layer" option
in a menu such as transparency or as a filter that also performs the function of
setting the alpha channel to 1.0 in all pixels of that layer.

This could provide easy editing of multiple layers with individual masks/alpha as
the combined alpha has messed up the mapping in a few cases as well as providing an easy
method of re-editing an image if the original is lost as TGA files only have one layer.

It also makes it easy to hide all unnecessary layers before using this "extract alpha channel"
function to extract the correct information if more than one layer is present.

The reason I say TGA is because that is the only format I know
of being used in this way and is very common for a wide range of 3d applications.

What do you think of these ideas on top on Joao's?

Joao S. O. Bueno wrote:

> On Sunday 20 July 2008, Raphaël Quinet wrote:
>
>> On Sun, 20 Jul 2008 21:22:11 +1000, Snake Arsenic
>>
> <snakearsenic@...> wrote:
>
>>> Okay I made a feature request at
>>> http://bugzilla.gnome.org/show_bug.cgi?id=543810 but it's missing
>>> a solution that will not remove any functionality. [...]
>>>
>
> Hi!
> Going beyond all of Raphael's excelent remarks, I still see some
> issues here :
> 1) The ability to "ciew teh layer sans transparency" and "edit the
> alpha channel as if it where any other channel" is provided in GIMP -
> you copy the alpha channel to the layer's mask, and edit it (the
> layer's mask).
>
> 2) The request indeed points a thing: GIMP _has_ the ability to set
> each channel "visible" or not - in the layers channel. If the <image>
> channel is disabled in the channels dialog, channel cvaleus are
> considere as zero for all display operations. However, setting the
> alpha channel to zero in this way - which is what gimp does -is
> useless - you just can't see anything in the image, as it is rendered
> with alpha = 0 for all layers.
> I'd suggest that when the alpha channekll si disabled in the channel
> dialog, image is rendered with alpha =1.0 (255) insetead. That
> would:
> a) enable the feature thought when the ability to run channel'son
> and off was included;
> b) Make gimp attend the requesterś (Snake) needs.
>
> Maybe the bug request should be chanegd accordingly?
>
> Moreover - I really think it is a more usefull (even if seldom used)
> behavior for disabling the alpha. What do you say of doing it?
>
>
>> I think that it would be a big mistake to use the alpha channel for
>> anything else than transparency. I assume that you are asking for
>> this because you have some program (I don't know which one) that is
>> incorrectly using the alpha channel to store bump map information
>> or something else that is not related to transparency. It is
>> likely that this program doesn't use a file format that supports
>> layers or independent channels, so its authors of have decided to
>> hijack the alpha channel in some existing file format.
>>
>
>
>> The correct way to solve this problem is to use layers instead of
>> abusing the alpha channel (or maybe additional channels, but I
>> think that using layers would be more convenient in this case).
>> With layers, it is very easy to toggle the visibility of the image
>> or the bump map layer, specular map layer or whatever else you are
>> working on.
>>
>> So instead of extending the mistakes done by the authors of some
>> other software, it would be much better to know what file format
>> has been subverted, and to perform the conversion in the file
>> plug-in: * When the plug-in loads a file that uses this strange
>> format, it would convert the alpha channel into a layer and mark
>> that layer (using a special name like the GIF plug-in does for
>> animations, because that can be edited easily by the user if
>> necessary).
>> * You would then be free to edit the image in GIMP and modify the
>> layer containing what should be visible or the layer containing the
>> bump map.
>> * When saving the file, the plug-in would detect that some layers
>> have a special name and would then combine these layers in a way
>> that can be read by whatever other program you are using.
>>
>> So I suggest that you:
>> 1) Identify what file formats need some special treatment.
>> 2) Check if there is a way to detect what files using that format
>> are special, so that we do not have to ask the user every time if a
>> file using that file format should be read in the intended way
>> (alpha channel = transparency) or in the non-standard way (bump
>> map). 3) Suggest improvements to the corresponding file plug-ins,
>> instead of requesting major changes in the GIMP core.
>> -Raphaël
>> _______________________________________________
>> Gimp-developer mailing list
>> Gimp-developer@...
>> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>>
>
>
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@...
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>

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

Re: Enhancement request - Use alpha channel for non-transparent information

2008-07-20T09:36:25Z

On Sunday 20 July 2008, Raphaël Quinet wrote:
> On Sun, 20 Jul 2008 21:22:11 +1000, Snake Arsenic
<snakearsenic@...> wrote:
> > Okay I made a feature request at
> > http://bugzilla.gnome.org/show_bug.cgi?id=543810 but it's missing
> > a solution that will not remove any functionality. [...]
>

Hi!
Going beyond all of Raphael's excelent remarks, I still see some
issues here :
1) The ability to "ciew teh layer sans transparency" and "edit the
alpha channel as if it where any other channel" is provided in GIMP -
you copy the alpha channel to the layer's mask, and edit it (the
layer's mask).

2) The request indeed points a thing: GIMP _has_ the ability to set
each channel "visible" or not - in the layers channel. If the <image>
channel is disabled in the channels dialog, channel cvaleus are
considere as zero for all display operations. However, setting the
alpha channel to zero in this way - which is what gimp does -is
useless - you just can't see anything in the image, as it is rendered
with alpha = 0 for all layers.
I'd suggest that when the alpha channekll si disabled in the channel
dialog, image is rendered with alpha =1.0 (255) insetead. That
would:
a) enable the feature thought when the ability to run channel'son
and off was included;
b) Make gimp attend the requesterś (Snake) needs.

Maybe the bug request should be chanegd accordingly?

Moreover - I really think it is a more usefull (even if seldom used)
behavior for disabling the alpha. What do you say of doing it?

> I think that it would be a big mistake to use the alpha channel for
> anything else than transparency. I assume that you are asking for
> this because you have some program (I don't know which one) that is
> incorrectly using the alpha channel to store bump map information
> or something else that is not related to transparency. It is
> likely that this program doesn't use a file format that supports
> layers or independent channels, so its authors of have decided to
> hijack the alpha channel in some existing file format.

> The correct way to solve this problem is to use layers instead of
> abusing the alpha channel (or maybe additional channels, but I
> think that using layers would be more convenient in this case).
> With layers, it is very easy to toggle the visibility of the image
> or the bump map layer, specular map layer or whatever else you are
> working on.
>
> So instead of extending the mistakes done by the authors of some
> other software, it would be much better to know what file format
> has been subverted, and to perform the conversion in the file
> plug-in: * When the plug-in loads a file that uses this strange
> format, it would convert the alpha channel into a layer and mark
> that layer (using a special name like the GIF plug-in does for
> animations, because that can be edited easily by the user if
> necessary).
> * You would then be free to edit the image in GIMP and modify the
> layer containing what should be visible or the layer containing the
> bump map.
> * When saving the file, the plug-in would detect that some layers
> have a special name and would then combine these layers in a way
> that can be read by whatever other program you are using.
>
> So I suggest that you:
> 1) Identify what file formats need some special treatment.
> 2) Check if there is a way to detect what files using that format
> are special, so that we do not have to ask the user every time if a
> file using that file format should be read in the intended way
> (alpha channel = transparency) or in the non-standard way (bump
> map). 3) Suggest improvements to the corresponding file plug-ins,
> instead of requesting major changes in the GIMP core.
> -Raphaël
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@...
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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

Re: Window resize

2008-07-20T08:17:47Z

On Fri, Jul 18, 2008 at 12:32 AM, Sven Neumann <sven@...> wrote:
> Hi,
>
> if you have questions on using GTK+, please ask on gtk-list or
> gtk-app-devel-list. Thanks.

Um, GtkWrapBox is part of Gimp, not GTK+, in spite of its name. (I have
no doubt that Sven knows that, and was reacting without having closely
read the question.)

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

Re: Enhancement request - Use alpha channel for non-transparent information

2008-07-20T06:07:01Z

On Sun, 20 Jul 2008 21:22:11 +1000, Snake Arsenic <snakearsenic@...> wrote:
> Okay I made a feature request at
> http://bugzilla.gnome.org/show_bug.cgi?id=543810 but it's missing a
> solution that will not remove any functionality. [...]

I think that it would be a big mistake to use the alpha channel for
anything else than transparency. I assume that you are asking for this
because you have some program (I don't know which one) that is
incorrectly using the alpha channel to store bump map information or
something else that is not related to transparency. It is likely that
this program doesn't use a file format that supports layers or independent channels, so its authors of have decided to hijack the
alpha channel in some existing file format.

The correct way to solve this problem is to use layers instead of
abusing the alpha channel (or maybe additional channels, but I think
that using layers would be more convenient in this case). With layers,
it is very easy to toggle the visibility of the image or the bump map
layer, specular map layer or whatever else you are working on.

So instead of extending the mistakes done by the authors of some other
software, it would be much better to know what file format has been
subverted, and to perform the conversion in the file plug-in:
* When the plug-in loads a file that uses this strange format, it would
convert the alpha channel into a layer and mark that layer (using a
special name like the GIF plug-in does for animations, because that
can be edited easily by the user if necessary).
* You would then be free to edit the image in GIMP and modify the layer
containing what should be visible or the layer containing the bump
map.
* When saving the file, the plug-in would detect that some layers have
a special name and would then combine these layers in a way that can
be read by whatever other program you are using.

So I suggest that you:
1) Identify what file formats need some special treatment.
2) Check if there is a way to detect what files using that format are
special, so that we do not have to ask the user every time if a file
using that file format should be read in the intended way (alpha
channel = transparency) or in the non-standard way (bump map).
3) Suggest improvements to the corresponding file plug-ins, instead of
requesting major changes in the GIMP core.

-Raphaël
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Enhancement request - Use alpha channel for non-transparent information

2008-07-20T04:22:11Z

Okay I made a feature request at
http://bugzilla.gnome.org/show_bug.cgi?id=543810 but it's missing a
solution that will not remove any functionality.

Martin mentioned something about supporting auxiliary channels in RGB
mode and I'm not sure what that means so if anyone could help me out on
that or give advise on how this could work. Also
http://bugzilla.gnome.org/show_bug.cgi?id=486902 was referenced and
again, I don't see how that relates to my feature request but I am open
to hear from anyone willing to explain.

A copy of the request is below.

When I use GIMP I sometimes use the alpha channel for things like bump maps,
specular maps or even parallax maps and would be good if there was a
check box
when you right-click the alpha layer that would enable/disable it's use for
transparency.

This could have the same effect as using the threshold alpha with a
setting of
0 while it's disabled.

Another way to do it could be if you make the alpha channel invisible it
would
look like the threshold alpha mentioned above and when only the alpha
channel
is selected then you could edit and apply effects to the alpha channel
as if it
were a custom channel.

This could apply with all channels but I believe the alpha channel needs
this
the most.

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

Re: GIMP metadata plug-in

2008-07-18T08:32:21Z

On Fri, 18 Jul 2008 19:04:47 +0400, "Alexandre Prokoudine" <alexandre.prokoudine@...> wrote:
> On Thu, Jul 17, 2008 at 12:52 PM, Roman Joost wrote:
> > Is there anyone who can give me valuable pointers? I try to come up with
> > something usable ...
>
> Raphael Quinet is the last guy who worked on it

I already offered my help to Roman via IRC and we discussed how to
proceed. Sorry for not mentioning it here.

-Raphaël
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: GIMP metadata plug-in

2008-07-18T08:04:47Z

On Thu, Jul 17, 2008 at 12:52 PM, Roman Joost wrote:

> Is there anyone who can give me valuable pointers? I try to come up with
> something usable ...

Raphael Quinet is the last guy who worked on it

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

Window resize

2008-07-18T01:13:50Z

Hello,

I have put some GtkButtons inside a Gtk V WrapBox (which is
a container) and then I've put this very GtkVWrapBox inside
a GtkWindow.

A GtkVWrapBox's job consists in placing all the GtkButtons
it contains in columns on its left-hand side.

If enough height is available, the GtkVWrapBox will
place all the GtkButtons in a single column on the left-hand side.
Otherwise, it will create as many columns as needed, thus requiring
more WIDTH to display the extra columns.

When the MOUSE resizes the GtkWindow which embarks my GtkVWrapBox,
I can't force this GtkWindow to resize properly to accomodate
the GtkVWrapBox. The result is that the GtkVWrapBox shrinks the
GtkButtons it contains to fit the space it is allowed by the
GtkWindow : this shrinkage is not a desired effect.

I am able to compute the space needed by the GtkVWrapBox to
display the GtkButtons full size. (by means of "gtk_widget_size_request"
on the GtkButtons it contains)

The problem is :
---------------
When the GtkWindow is resized with the mouse, I can't have it resized
according to the constraints I have calculated with gtk_widget_size_request.
When the GtkWindow is resized with the mouse, it seems to receive two
signals from the "window manager"(?) :
1) "size-request" and
2) "size-allocate"

I tried the following strategies to solve my problem :

1)Issue a "gtk_widget_set_size_request" on the GtkWindow in the "size-request"
callback.
2)Issue a "gtk_widget_set_size_request" on the GtkWindow in the "size-allocate"
callback.
3)Issue a "gtk_window_setsize" (GTK) on the GtkWindow in the "size-request"
callback.
4)Issue a "gtk_window_setsize" (GTK) on the GtkWindow in the "size-allocate"
callback.
5)Issue a "gdk_window_setsize" (GDK) on the GtkWindow->window in the
"size-request" callback.
6)Issue a "gdk_window_setsize" (GDK) on the GtkWindow->window in the
"size-allocate" callback.
7)Issue a "gtk_window_set_geometry_hints" on the GtkWindow in the
"size-request" callback.
9)Issue a "gtk_window_set_geometry_hints" on the GtkWindow in the
"size-allocate" callback.

I also programmed my GtkWindow with gtk_window_set_geometry_hints to
have it resized by increments (increment in height : the height of a
GtkButton inside my GtkVWrapBox / increment in width : the width of a
GtkButton inside my GtkVWrapBox)

HINT :
------
The GIMP also embarks a GtkWrapBox. When the window is resized with
the mouse, it does so by moving its right-bottom corner by increments.

But the trick is that if the height is reduced and the GtkVWrapBox is
on the brink of creating a new column to compensate for the loss of
height, the GtkWindow ANTICIPATES by both decrementing its height
and incrementing its width AT THE SAME TIME.

Does anyone knows how to do that ?

Thanks.

Re: Window resize

2008-07-18T00:32:19Z

Hi,

if you have questions on using GTK+, please ask on gtk-list or
gtk-app-devel-list. Thanks.

Sven

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

GIMP metadata plug-in

2008-07-17T01:52:52Z

Hi,

I'd like to hack on the metadata browser (plug-ins/metadata). I'm
currently trying to get an overview of the plug-in. The README file
provides valuable facts about what's currently implemented. A lot of
code is currently commented out.

Is there anyone who can give me valuable pointers? I try to come up with
something usable ...

Cheers,
--
Roman Joost
www: http://www.romanofski.de
email: romanofski@...

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

signature.asc (196 bytes) Download Attachment

Re: need help with bug #464466 (downscaling quality)

2008-07-16T23:20:47Z

On Thu, Jul 17, 2008 at 2:32 PM, Guillermo Espertino
<gespertino@...> wrote:
> Please consider adding typographic elements (logos, text) and
> icons/diagrams to the test images.
> One of the most critic use cases where downscaling shows issues is with
> high contrast such as dark typography on light backgrounds.
> This is particularly important when working with small designs for the
> web (banners, for instance, which end up too blurry).
I believe that most blurring problems originate from incorrect gamma
treatment .. the interpolation done during scaling and other
operations is only accurate if done in linear RGB colorspace, whereas
predominantly people use the sRGB colorspace which is nonlinear (up to
50% error can occur from interpolating sRGB values as if they were
linear.). Working in "CIE 1931 D65 Gamma 1.0" colorspace and
eventually converting to 'nativePC" profile to produce the final
picture might well improve your results. It has made my results
smoother and crisper.

(the profiles mentioned above are available from:
http://www.aim-dtp.net/aim/techniques/linear_raw/index.htm)

That said, if you provide a suitable typographical test image, I will
include it.
( I see no issue that a diagrammatic test image would show up that
wouldn't already appear on either Liam's complex engravings or a
typographical test image. So unless you demonstrate that, I will not
include a diagrammatic test image)

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

Re: need help with bug #464466 (downscaling quality)

2008-07-16T23:14:36Z

Hi,

On Thu, Jul 17, 2008 at 7:35 AM, Sven Neumann <sven@...> wrote:

> Hi,
>
> On Thu, 2008-07-17 at 09:19 +0930, David Gowers wrote:
>
>> Personally I think the test is being run under flawed conditions
>> (using nonlinear sRGB rather than linear RGB, which produces errors of
>> up to 50% because interpolation is done linearly despite the
>> colorspace being nonlinear.). However, those are the conditions the
>> user is predominantly working under.
>> I'm considering doing a separate test run where I first convert to
>> linear RGB and finally convert back to sRGB.
>
> Please don't overdo it. All we need to know at this point is that the
> patch is an improvement. It doesn't have to solve all problems, it just
> needs to provide a somewhat better result than the old code.
>
> Processing in linear space will happen automatically as soon as we
> switch all processing to GEGL. We are not going to make the legacy code
> even more complex than it already is. So please don't waste your time on
> this.

That's unrelated. I simply meant that I currently work in linear space
anyway, and what I meant involves no code changes, just converting
between color profiles during testing to ensure more accurate
interpolation. (my point also was that it's hard to tell if it's doing
something better, when the distorted interpolation presents
significant artefacts obscuring it). Anyway -- okay, I won't do that.

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

Re: need help with bug #464466 (downscaling quality)

2008-07-16T22:02:36Z

Please consider adding typographic elements (logos, text) and
icons/diagrams to the test images.
One of the most critic use cases where downscaling shows issues is with
high contrast such as dark typography on light backgrounds.
This is particularly important when working with small designs for the
web (banners, for instance, which end up too blurry).

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

Re: need help with bug #464466 (downscaling quality)

2008-07-16T16:49:50Z

> Here are some images that may help show some problems -- colour photos
> tend to hide problems, partly because the eye sees the subject more
> easily and auto-corrects flaws, and partly because the hardest thing
> for rescaling is often preserving both texture and sharpness. Of
> course, most people are working with colour photos these days...)

Personally I think the test is being run under flawed conditions
(using nonlinear sRGB rather than linear RGB, which produces errors of
up to 50% because interpolation is done linearly despite the
colorspace being nonlinear.). However, those are the conditions the
user is predominantly working under.
I'm considering doing a separate test run where I first convert to
linear RGB and finally convert back to sRGB.

>
> For potential problems with vertical artifacts, see the
> 1600x1200 image at
> http://www.fromoldbooks.org/Green-ShortHistory/pages/0187-Remains-of-Cloisters/
> (I had to resize it to 1024x768 using cubic and then sharpen)
>
> The 1518x916 one at
> http://www.fromoldbooks.org/YouthsInstructer/pages/072-New-Post-Office-London/
> has near-horizontal lines which are difficult.
>
> http://www.fromoldbooks.org/YouthsInstructer/pages/181-Dunluce-Castle/181-Dunluce-Castle-q59-1447x923.jpg
> has diagonals and is an RGB image instead of grayscale.
>
> http://www.fromoldbooks.org/ThomasBewick-WoodEngravings/pages/30-the-horse/1790x1307-q75.html
> is a fairly clean woodcut.

All these seem good, so I've included them. I'm currently searching
for Geert's images.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: need help with bug #464466 (downscaling quality)

2008-07-16T15:05:47Z

Hi,

On Thu, 2008-07-17 at 09:19 +0930, David Gowers wrote:

> Personally I think the test is being run under flawed conditions
> (using nonlinear sRGB rather than linear RGB, which produces errors of
> up to 50% because interpolation is done linearly despite the
> colorspace being nonlinear.). However, those are the conditions the
> user is predominantly working under.
> I'm considering doing a separate test run where I first convert to
> linear RGB and finally convert back to sRGB.

Please don't overdo it. All we need to know at this point is that the
patch is an improvement. It doesn't have to solve all problems, it just
needs to provide a somewhat better result than the old code.

Processing in linear space will happen automatically as soon as we
switch all processing to GEGL. We are not going to make the legacy code
even more complex than it already is. So please don't waste your time on
this.

Sven

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

Re: need help with bug #464466 (downscaling quality)

2008-07-16T14:25:12Z

On Wed, 16 Jul 2008 17:15:38 +0200, Liam R E Quin <liam@...> wrote:

> On Wed, 2008-07-16 at 22:14 +0930, David Gowers wrote:
>
>> > The one thing I definitely can't do is
>> > * Host webpage.
>
> I can do that if you want, although gimp.org would be better.
> As long as it's under a gigabyte or so.
>
> Here are some images that may help show some problems -- colour photos
> tend to hide problems, partly because the eye sees the subject more
> easily and auto-corrects flaws, and partly because the hardest thing
> for rescaling is often preserving both texture and sharpness. Of
> course, most people are working with colour photos these days...)
>

I posted some good test images when I was working on the lanczos part of
this code and the rotation distortions. Concentric circles and the like.
These geometric patterns make any defect instantly visible whereas it may
not be obvious in one operation on a photo-like image.

care should be taken not to assume the criteria is one or two simple ops
on photos. Gimp vision specifies graphics as well as photos so defects in
geometric shapes are highly relevant.

I also posted a woodpecker photo that had a near horizontal beak section.
I found this was a very sensitive test for staircasing defects that may be
relevant here.

Search bugs for lanczos or rotation to find these bug reports containing
attachments.

regards.

> For potential problems with vertical artifacts, see the
> 1600x1200 image at
> http://www.fromoldbooks.org/Green-ShortHistory/pages/0187-Remains-of-Cloisters/
> (I had to resize it to 1024x768 using cubic and then sharpen)
>
> The 1518x916 one at
> http://www.fromoldbooks.org/YouthsInstructer/pages/072-New-Post-Office-London/
> has near-horizontal lines which are difficult.
>
> http://www.fromoldbooks.org/YouthsInstructer/pages/181-Dunluce-Castle/181-Dunluce-Castle-q59-1447x923.jpg
> has diagonals and is an RGB image instead of grayscale.
>
> http://www.fromoldbooks.org/ThomasBewick-WoodEngravings/pages/30-the-horse/1790x1307-q75.html
> is a fairly clean woodcut.
>
> I have some much larger images too if you want them.
>
> Liam
>

--

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

Re: need help with bug #464466 (downscaling quality)

2008-07-16T12:30:45Z

Hi,

On Wed, 2008-07-16 at 18:30 +0930, David Gowers wrote:

> The one thing I definitely can't do is
> * Host webpage.

I don't think we have enough space currently on gimp.org to host this.
But it doesn't really matter where it is hosted. I can put the stuff
online if you give me a tarball that I can just unpack on my web server.

Sven

PS: The images that Liam offered look very useful btw. You should
consider to use them (or some of them) for your tests.

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

Re: need help with bug #464466 (downscaling quality)

2008-07-16T08:15:38Z

On Wed, 2008-07-16 at 22:14 +0930, David Gowers wrote:

> > The one thing I definitely can't do is
> > * Host webpage.

I can do that if you want, although gimp.org would be better.
As long as it's under a gigabyte or so.

Here are some images that may help show some problems -- colour photos
tend to hide problems, partly because the eye sees the subject more
easily and auto-corrects flaws, and partly because the hardest thing
for rescaling is often preserving both texture and sharpness. Of
course, most people are working with colour photos these days...)

For potential problems with vertical artifacts, see the
1600x1200 image at
http://www.fromoldbooks.org/Green-ShortHistory/pages/0187-Remains-of-Cloisters/
(I had to resize it to 1024x768 using cubic and then sharpen)

The 1518x916 one at
http://www.fromoldbooks.org/YouthsInstructer/pages/072-New-Post-Office-London/
has near-horizontal lines which are difficult.

http://www.fromoldbooks.org/YouthsInstructer/pages/181-Dunluce-Castle/181-Dunluce-Castle-q59-1447x923.jpg
has diagonals and is an RGB image instead of grayscale.

http://www.fromoldbooks.org/ThomasBewick-WoodEngravings/pages/30-the-horse/1790x1307-q75.html
is a fairly clean woodcut.

I have some much larger images too if you want them.

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: need help with bug #464466 (downscaling quality)

2008-07-16T05:44:11Z

Hi,
I've just completed producing images without the patch (using old
scaling code) for None and Linear methods.
This amounts to 2*77 = 154 images totalling 110 MB. Some of these I
plan to discard, for the cases where the old and new code produce the
same result.

One of the photos had transparency information added to it, another
which was already grey I converted to greyscale.

Remaining:
* produce 77 images each for Cubic and Lanczos
* (possibly) produce 77 images each for None, Linear, Cubic, and
Lanczos using the patch
* (possibly) check whether scaling in Indexed modefor the pixel art
produces identical results to None using RGB mode
* (possibly) make webpage.

On Wed, Jul 16, 2008 at 6:30 PM, David Gowers <00ai99@...> wrote:

> I can do at least half of this task, possibly most of it.
>
> * decide on test images:
> 2 landscapes
> http://www.flickr.com/photos/hapal/2292885459/sizes/l/
> http://www.flickr.com/photos/15082599@N08/2432037855/sizes/l/ (or size o/ )
> 3 portraits
> http://www.flickr.com/photos/aturkus/2091469097/sizes/l/
> http://www.flickr.com/photos/manicomi/2472143804/sizes/l/
> http://flickr.com/photos/newroz2005/9392539/sizes/o/in/pool-88292168@N00/
> 1 cartoon
> http://www.flickr.com/photos/stephendl/2536595458/sizes/o/
> 1 pixel art
> http://www.pixeljoint.com/pixelart/5647.htm#
>
> * decide on tests:
> Scale down, single step:
> 50% 33% 12.5%
> Scale up, single step:
> 133% 150% 200% 400%
> Scale down, multiple steps
> (to 66% x 3), (to 50% x 3)
> Scale up, multiple steps
> (to 133% x 3), (to 150% x 3)
>
>
> * Save results of tests before applying patch
> * (probably) Save results of tests after applying patch
> * Make webpage
>
> The one thing I definitely can't do is
> * Host webpage.

I might be able to make a PDF.I suspect the smallest it could possibly
get is 20mb.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: need help with bug #464466 (downscaling quality)

2008-07-16T02:00:17Z

I can do at least half of this task, possibly most of it.

* decide on test images:
2 landscapes
http://www.flickr.com/photos/hapal/2292885459/sizes/l/
http://www.flickr.com/photos/15082599@N08/2432037855/sizes/l/ (or size o/ )
3 portraits
http://www.flickr.com/photos/aturkus/2091469097/sizes/l/
http://www.flickr.com/photos/manicomi/2472143804/sizes/l/
http://flickr.com/photos/newroz2005/9392539/sizes/o/in/pool-88292168@N00/
1 cartoon
http://www.flickr.com/photos/stephendl/2536595458/sizes/o/
1 pixel art
http://www.pixeljoint.com/pixelart/5647.htm#

* decide on tests:
Scale down, single step:
50% 33% 12.5%
Scale up, single step:
133% 150% 200% 400%
Scale down, multiple steps
(to 66% x 3), (to 50% x 3)
Scale up, multiple steps
(to 133% x 3), (to 150% x 3)

* Save results of tests before applying patch
* (probably) Save results of tests after applying patch
* Make webpage

The one thing I definitely can't do is
* Host webpage.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: need help with bug #464466 (downscaling quality)

2008-07-15T22:58:30Z

Hi,

On Tue, 2008-07-15 at 09:49 -0400, Liam R E Quin wrote:

> I can certainly offer images, I'm maxed out with work & meetings & stuff
> this month though, so apart from that I don't have spare cycles probably
> until the end of the month. Sorry for not replying first time round.

I don't think images are the problem. What we need is a nice comparison,
somewhat similar to http://users.telenet.be/geert.jordaens/ (except that
this page was not created using the latest version of the code and that
the links to the full-scale versions of the images appear to be broken).
But thanks for your offer. Perhaps if we find someone to do the
comparison, he/she will come back to you and ask your for those images.

Sven

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

Re: po-files in SVN need updating

2008-07-15T08:03:56Z

Hi,

On Tue, 2008-07-15 at 16:27 +0930, David Gowers wrote:

> It looks to me like nobody remembered to update the .po files after
> the menu reorganization. (or is the reorganization still ongoing?)
> Is this an oversight or is it not the right time to do that yet?

It is not our job to update the po files. The translators do that (using
intltool) before they start to work on the translations. Or they
download uptodate po files from l10n.gnome.org. The files in SVN only
change when a translators commits an update.

And what you claim is not true. The German translation at least has the
words that you mentioned translated. You probably missed that because
you grepped for the words without mnemonics.

Sven

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

Re: need help with bug #464466 (downscaling quality)

2008-07-15T06:49:45Z

On Tue, 2008-07-15 at 00:32 +0200, Sven Neumann wrote:

> Since no one has offered to help with this bug so far, I see two
> options:
>
> (1) postpone this change for 2.8
> (2) commit the changes and release them with 2.5.2, revert if needed

I can certainly offer images, I'm maxed out with work & meetings & stuff
this month though, so apart from that I don't have spare cycles probably
until the end of the month. Sorry for not replying first time round.

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

po-files in SVN need updating

2008-07-14T23:57:05Z

I am currently learning esperanto, and I set GIMP language to
esperanto. Then, I noticed that there were several things
untranslated, which the po file did not even record the original
string for! (ie there is not even a 'msgid' showing the untranslated
message!)
For example
* File->New ( the submenu New, not 'New...' which is correctly
translated as 'Nova'), along with some of its items.
* Edit->Modules and Edit->Units
* Filters->Decor ('Decor' remains untranslated, though its contents
are correctly translated)
* 'Windows' menu and both of its submenus

These elements are untranslated in all languages due to this; none of
the po files cover any of the above, according to grep.

It looks to me like nobody remembered to update the .po files after
the menu reorganization. (or is the reorganization still ongoing?)
Is this an oversight or is it not the right time to do that yet?

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

Re: Tagging of Gimp Resources project status

2008-07-14T18:10:34Z

Hello,

On Tue, Jul 15, 2008 at 10:01 AM, David Gowers <00ai99@...> wrote:

> On Tue, Jul 15, 2008 at 1:06 AM, Bill Skaggs <weskaggs@...> wrote:
>> Here is to me the most important question. Suppose the user wants
>> to switch back and forth among a few brushes that don't have any
>> natural relationship. Suppose for example that the user wants to draw
>> with a pencil brush, and then erase parts of the drawing with a round
>> parametric brush, and repeat the cycle. Is this sort of thing going to
>> be supported in a way that is easy for the user?
>>
>> -- Bill
>
> Cycling between the brushes in the filtered view could do this (so,
> tag both with 'quickdraw' then use the action -- notice their ordering
> is not user-controllable in this scenario). I think 'next brush' and
> 'previous brush' actions that already exist should handle this.
>
> However, they appear not to cycle currently -- ie going back from the
> first brush leaves you at the first brush rather than the last, and
> vice versa.
> This should really be fixed -- cycling makes more sense for
> GimpData's (brush, pattern, palette) than the current, clipping,
> behaviour.
> Looking at the code in app/actions/actions.c, it seems that all we
> need is to change action_select_object() to support wrapping, and then
> use that parameter (in context-commands.c and layers-commands.c).
>
> A diff is attached that implements the suggested changes.

.. I am puzzled by how this message got double posted.

I left a file out of the diff and some formatting was incorrect. Here
is the revised diff.

[cycle-gimpdata.diff]

Index: app/actions/actions.c =================================================================== --- app/actions/actions.c (revision 26193) +++ app/actions/actions.c (working copy) @@ -511,7 +511,8 @@ GimpObject * action_select_object (GimpActionSelectType select_type, GimpContainer *container, - GimpObject *current) + GimpObject *current, + gboolean wrap) { gint select_index; gint n_children; @@ -561,7 +562,14 @@ break; } - select_index = CLAMP (select_index, 0, n_children - 1); + if (wrap) + { + while (select_index < 0) + select_index = (n_children) - (0 - select_index); + + while (select_index > (n_children - 1)) + select_index = (n_children - select_index); + } return gimp_container_get_child_by_index (container, select_index); } Index: app/actions/actions.h =================================================================== --- app/actions/actions.h (revision 26193) +++ app/actions/actions.h (working copy) @@ -51,7 +51,8 @@ gboolean wrap); GimpObject * action_select_object (GimpActionSelectType select_type, GimpContainer *container, - GimpObject *current); + GimpObject *current, + gboolean wrap); #define return_if_no_gimp(gimp,data) \ Index: app/actions/layers-commands.c =================================================================== --- app/actions/layers-commands.c (revision 26193) +++ app/actions/layers-commands.c (working copy) @@ -348,7 +348,8 @@ new_layer = (GimpLayer *) action_select_object ((GimpActionSelectType) value, image->layers, - (GimpObject *) layer); + (GimpObject *) layer, + FALSE); if (new_layer && new_layer != layer) { Index: app/actions/context-commands.c =================================================================== --- app/actions/context-commands.c (revision 26193) +++ app/actions/context-commands.c (working copy) @@ -680,7 +680,7 @@ current = gimp_context_get_by_type (context, container->children_type); - current = action_select_object (select_type, container, current); + current = action_select_object (select_type, container, current, TRUE); if (current) gimp_context_set_by_type (context, container->children_type, current);

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