Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing

[Adalbert Hanßen]

Am 09.07.22 um 03:36 schrieb Jacob Boerema:


On 2 Jun 2022 at 11:45, Adalbert Hanßen wrote:


I use GNU Image Manipulation Program Version 2.10.18 on Xubuntu 20.04.4
LTS (64 Bit).

There have been a lot of improvements to our metadata handling after
version 2.10.18. I would suggest trying the latest version 2.10.32, possibly as
a flatpak, because you also need the latest exiv2 and gexiv2 for up-to-date
metadata handling.

...


Jacob, thank you for the response. First I was a bit sceptical if Gimp 
installed as Flatpak can access files from |/tmp |which I often use in 
order to take delayed screenshots by a shortcut like this:


xfce4-screenshooter -fmd 7 -o gimp

Once I had Gimp installed as a Snap and it did not work for delayed 
screenshots because Snaps have difficulties accessing |/tmp|. Perhaps 
Flatpak behaves differently.


I gave it a try to install the current version of Gimp in parallel with

sudo flatpak installhttps://flathub.org/repo/appstream/org.gimp.GIMP.flatpakref

and I only had to change the screenshot call to

xfce4-screenshooter -fmd 7 -o "flatpak run org.gimp.GIMP//stable"

in order to continue working (the double quotation marks are crucial!)
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing

[Liam R E Quin]

On Fri, 2022-07-08 at 18:45 -0600, Akkana Peck wrote:
> 
> 
> Once we get to non-destructive editing using GEGL ops, I could
> imagine an EXIF field listing a set of ops used for processing.

Undo history in exif might be interesting, agreed, although i think it
remains to be seen how that'd work for e.g. brush strokes. I was
wondering if the original poster had a use for it today, though :)

-- 
Liam Quin - https://www.fromoldbooks.org/
with fabulous vintage art and fascinating texts to read.
https://www.delightfulcomputing.com/
Full-time "slave" in voluntary servitude
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing

[Jacob Boerema via gimp-developer-list]

On 2 Jun 2022 at 11:45, Adalbert Hanßen wrote:

> I use GNU Image Manipulation Program Version 2.10.18 on Xubuntu 20.04.4 
> LTS (64 Bit).

There have been a lot of improvements to our metadata handling after 
version 2.10.18. I would suggest trying the latest version 2.10.32, possibly as 
a flatpak, because you also need the latest exiv2 and gexiv2 for up-to-date 
metadata handling.

Besides that, camera makers are part of the problem. They introduce all 
kinds of proprietary data with every new model. It is always a race to keep 
up-to-date with new info from all brands and models.

Anyway. If an up-to-date GIMP with up-to-date metadata libraries as 
mentioned above still has problems, then the best thing to do is open an 
issue, with a zipped (or otherwise compressed) example image attached. It 
needs to be zipped, because GitLab  usually removes most metadata from 
images.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing

[Akkana Peck]

> On Thu, 2022-06-02 at 11:45 +0200, Adalbert Hanßen wrote:
> > *Suggested further improvement:* Add a new category “Gimp Processing”
> > telling about the image processing procedures applied, e.g. lighting 
> > adjustments and their parameters, color adjustment, cropping, and the
> > like in readable form.

Liam R E Quin writes:
> It's an interesting idea - how would this information be used?

Once we get to non-destructive editing using GEGL ops, I could
imagine an EXIF field listing a set of ops used for processing.
Imagine being able to save as JPEG yet still be able to load
back into GIMP and undo the last few ops. Yes, there would be some loss
of quality because of lossy compression, and it's certainly not a
substitute for saving as XCF, but I can imagine cases where it
might be useful anyway.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing

[Liam R E Quin]

On Thu, 2022-06-02 at 11:45 +0200, Adalbert Hanßen wrote:
> 
> but not shown in Gimp, e.g. the Lens Type.
> 
> *W**hy does Gimp not show the **le**ns**type?*

Can you share a sample image?

When you export as JPEG make sure "save exif" is checked!

> 
> *Suggested further improvement:* Add a new category “Gimp Processing”
> telling about the image processing procedures applied, e.g. lighting 
> adjustments and their parameters, color adjustment, cropping, and the
> like in readable form.

It's an interesting idea - how would this information be used?

liam / ankh / demib0y / barefootliam

-- 
Liam Quin - https://www.fromoldbooks.org/

Full-time "slave" in voluntary servitude
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug

[Alexandre Prokoudine via gimp-developer-list]

On Fri, Nov 27, 2020 at 6:44 PM Gregory Reshetniak wrote:

> No Alex, every communication channel reposting GIMP news is full of your
> comments like "piss off or make pull requests" and it's ing tiresome to
> be observing for years on end.
> You want to be a spokesperson? Well then behave like one.
>

I'm not sure what caused this continuous urge to look for offense where no
offense was meant, and I'd rather not speculate. But I'm afraid I have to
point out that you are balancing right on the edge of violating our code
of conduct: https://www.gimp.org/mail_lists.html#code-of-conduct

Please adhere to it.

Alex

>
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug

[Gregory Reshetniak via gimp-developer-list]

No Alex, every communication channel reposting GIMP news is full of your
comments like "piss off or make pull requests" and it's ing tiresome to
be observing for years on end.
You want to be a spokesperson? Well then behave like one.

On Fri, 27 Nov 2020 at 16:34, Alexandre Prokoudine via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> On Fri, Nov 27, 2020 at 6:28 PM Gregory Reshetniak wrote:
>
> > "Dear Albert Einstein, unfortunately there hasn't been a MacOS expert to
> > help us fix the release process yet. Hopefully someone will appear soon -
> > we'd really want to continue releasing for Macs again. Perhaps you might
> > help us with it? Here are the tasks that need to be done
> > https://gitlab.gnome.org/GNOME/gimp/-/issues/4504;
> >
> > See Alex, it's possible to reply to completely innocent questions without
> > full force of your passive aggressive ego scaring away users and even
> > possible contributors. Try it, we believe in you.
> >
>
> You replied with aggression to a short, concise reply that implied no
> aggression whatsoever, passive or otherwise.
>
> Do I need to point out that this sort of behavior is not appreciated here?
>
> Please do not do that again. Thank you.
>
> Alex
>
> >
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>


-- 

Gregory Reshetniak
about.me/gregory.reshetniak

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug

[Alexandre Prokoudine via gimp-developer-list]

On Fri, Nov 27, 2020 at 6:28 PM Gregory Reshetniak wrote:

> "Dear Albert Einstein, unfortunately there hasn't been a MacOS expert to
> help us fix the release process yet. Hopefully someone will appear soon -
> we'd really want to continue releasing for Macs again. Perhaps you might
> help us with it? Here are the tasks that need to be done
> https://gitlab.gnome.org/GNOME/gimp/-/issues/4504;
>
> See Alex, it's possible to reply to completely innocent questions without
> full force of your passive aggressive ego scaring away users and even
> possible contributors. Try it, we believe in you.
>

You replied with aggression to a short, concise reply that implied no
aggression whatsoever, passive or otherwise.

Do I need to point out that this sort of behavior is not appreciated here?

Please do not do that again. Thank you.

Alex

>
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug

[Gregory Reshetniak via gimp-developer-list]

"Dear Albert Einstein, unfortunately there hasn't been a MacOS expert to
help us fix the release process yet. Hopefully someone will appear soon -
we'd really want to continue releasing for Macs again. Perhaps you might
help us with it? Here are the tasks that need to be done
https://gitlab.gnome.org/GNOME/gimp/-/issues/4504;

See Alex, it's possible to reply to completely innocent questions without
full force of your passive aggressive ego scaring away users and even
possible contributors. Try it, we believe in you.

On Fri, 27 Nov 2020 at 16:14, Alexandre Prokoudine via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> On Fri, Nov 27, 2020 at 4:27 PM Albert Einstein via
> gimp-developer-list  wrote:
> >
> > Are there any news about the release of the new and fixed version for
> MacOS ?
>
> There will be once someone joins the team to work on macOS builds.
>
> Alex
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>


-- 

Gregory Reshetniak
about.me/gregory.reshetniak

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug

[Alexandre Prokoudine via gimp-developer-list]

On Fri, Nov 27, 2020 at 4:27 PM Albert Einstein via
gimp-developer-list  wrote:
>
> Are there any news about the release of the new and fixed version for MacOS ?

There will be once someone joins the team to work on macOS builds.

Alex
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug

[Albert Einstein via gimp-developer-list]

Are there any news about the release of the new and fixed version for MacOS ?

Sent from my iPhone



> On 10/17/20 8:27 AM, Albert Einstein via gimp-developer-list wrote:
> 
> Dear Developers,

Hi Albert,

> I have noticed a bug on the iMac version:
> 
> When I am opening a pdf file, and select 300dpi resolution, then, when I go 
> to Scale Image, I see that the resolution has changed to 72dpi, but the 
> overall size in pixels remains the same.
> 
> Then, if I export this file it is converted into a massive file (in pixels) 
> to compensate the drop of resolution. I do not have this problem with the PC 
> version.
> 

> Could you please look into it and fix it?

this is the following issue:
https://gitlab.gnome.org/GNOME/gimp/-/issues/4194

Ironically, this was caused by a change done to prevent the current
default value of 300 ppi from unconditionally overwriting any value an
imported image might specify instead.

It is fixed as of 2.10.16, but unfortunately we currently do not have
anyone who can build the macOS packages.


--
Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug in 2.10.22 Menu -> Picture -> Metadaten

[Liam R E Quin]

On Mon, 2020-10-19 at 21:45 +0200, LUP wrote:
>  
> 
> Bug in 2.10.22 Menu -> Picture -> Metadata
> 
>  
> 
> Saving metadata doesn't work

Could you give us more details?
* which GIMP version
* complete and detailed steps to reproduce the problem

It seems to work here.

(sorry for a  delayed response here, looks like your mail got stuck in
a moderation queue)

-- 
Liam Quin - web slave for https://www.fromoldbooks.org/
with fabulous vintage art and fascinating texts to read.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug

[Michael Schumacher]

On 10/17/20 8:27 AM, Albert Einstein via gimp-developer-list wrote:

> Dear Developers,

Hi Albert,

> I have noticed a bug on the iMac version:
>
> When I am opening a pdf file, and select 300dpi resolution, then, when I go 
> to Scale Image, I see that the resolution has changed to 72dpi, but the 
> overall size in pixels remains the same.
>
> Then, if I export this file it is converted into a massive file (in pixels) 
> to compensate the drop of resolution. I do not have this problem with the PC 
> version.
>

> Could you please look into it and fix it?

this is the following issue:
https://gitlab.gnome.org/GNOME/gimp/-/issues/4194

Ironically, this was caused by a change done to prevent the current
default value of 300 ppi from unconditionally overwriting any value an
imported image might specify instead.

It is fixed as of 2.10.16, but unfortunately we currently do not have
anyone who can build the macOS packages.


--
Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug

[Christopher Curtis via gimp-developer-list]

You are using a newer version on the PC than you are on the Mac.

Can you install a newer Mac version? It seems you may need to use Macports,
Homebrew, or Fink.
https://www.gimp.org/downloads/

I don't see anything obvious in the Changelogs, but if that doesn't work,
try version 2.10.14 on the PC and see if it behaves the same way. If it
does then the new version has already fixed the problem.

Chris


On Sat, Oct 17, 2020 at 6:22 AM Albert Einstein via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Dear Developers,
>
>
>
> I am using gimp since a long time, and I am loving it!
>
> You’ve done a fantastic job with it! Thank you!
>
>
>
> Currently I am using it on my iMac (v2.10.14) and my PC (v2.10.22).
>
>
>
> I have noticed a bug on the iMac version:
>
> When I am opening a pdf file, and select 300dpi resolution, then, when I
> go to Scale Image, I see that the resolution has changed to 72dpi, but the
> overall size in pixels remains the same.
>
> Then, if I export this file it is converted into a massive file (in
> pixels) to compensate the drop of resolution. I do not have this problem
> with the PC version.
>
>
>
> Could you please look into it and fix it?
>
>
>
> Thank you,
>
> Albert Einstein
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] bug in GIMP 2.10.2?

[Pat David]

Are you exporting the image, or trying to save?

If you want a jpg or png file, you'll need to export it.

On Sun, Jun 10, 2018 at 2:37 PM bernard M  wrote:

> Hello
> when I try to put a layer with a fading color above a picture, there is
> no issue. But when I want to make a record on my computer, only the
> picture is present, the new layer is not recorded.
> This issue didn't appear in the precedent version of GIMP.
> What can I do?
> Thanks for your solution
> B Mahyer, France
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
-- 
https://patdavid.net
GPG: 66D1 7CA6 8088 4874 946D  18BD 67C7 6219 89E9 57AC
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug reports on PhotoShop "adjustment layers" vs "layer styles"

[Elle Stone]

On 02/06/2018 10:30 AM, Øyvind Kolås wrote:

On Tue, Feb 6, 2018 at 4:15 PM, Elle Stone
 wrote:

 From the vantage point of "GEGL code in 2018", are the functionalities of
PhotoShop "adjustment layers" and "layer styles" similar enough from an
implementation point of view that both could be implemented all at once,
using the same GEGL code? Or would there need to be substantially
different/additional code for layer styles, compared to adjustment layers?


Yes - both are non-destructive editing features, and can be
impleemnted by inserting additional GeglNodes in the chain/graph of
nodes that represent the layer stack. Applying a drop-shadow to the
raster output of a part is no different from applying a color
adjustment. The live previews done for GEGL based filters in GIMP-2.9
are already done by inserting a temporary one-off adjustment layer on
the relevant layer, "inside a layer group".

/pippin



Pippin - thanks!

Best,
Elle
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug report in Levels control

[Carol Spears]

On Thu, Aug 31, 2017 at 10:44 PM, Ben Hutchinson  wrote:

> The Levels control (the dialog box you get with Ctrl+L) has a bug. When you
> select Value for the channel, it is supposed to have a histogram which is
> based on all of the color channels combined. However, this bug causes the
> Value channel for the histogram to only consider the green channel. The
> result is that when you select either Value or Green for the color channel,
> you get identical histograms. The levels sliders themselves work correctly.
> It's just the histogram that has the problem.
>
>
>
Early gimp (gimp-1.0.0 thru gimp-1.0.3 iirc) had some breakage on the red
channel.  You could start with a grayscale image, convert it to RGB and
using levels (at least, maybe other tools) change an image of blacks,
whites and grays to an image of reds.

Here is a tutorial that utilized this bug:
https://web.archive.org/web/20010107023700/http://at8.abo.fi:80/~mwikholm/com/gimp/tutor/glass/

I suspect that it has always been this way.

Let me know if you file a bug report about it.  This is just great!

carol
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug report in Levels control

[Carol Spears]

On Thu, Aug 31, 2017 at 10:44 PM, Ben Hutchinson  wrote:

> The Levels control (the dialog box you get with Ctrl+L) has a bug. When you
> select Value for the channel, it is supposed to have a histogram which is
> based on all of the color channels combined. However, this bug causes the
> Value channel for the histogram to only consider the green channel. The
> result is that when you select either Value or Green for the color channel,
> you get identical histograms. The levels sliders themselves work correctly.
> It's just the histogram that has the problem.
>
> This bug is present in the latest beta/development version (at the time I
> wrote this email) of Gimp.
> That is version 2.9.4 commit 5afea2f
> Note that I'm using the Windows version of Gimp, not the Linux version (not
> sure if there are any differences between these 2 in functionality).
>

First, make sure you can reproduce it (ie, here it is the red channel, and
I never noticed that).

Second: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP
Perhaps attach a screenshot or not.  If you can figure out how to fix it,
patches for stuff like this are usually well received.

Also, this is kind of funny to me.  I wonder how far back this oddity goes.

carol
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] bug? xsetwacom setting MapToOutput breaks mouse functionality in 2.9.5

[Casey Connor]

...and by dint of the universal "you figure it out right after you email 
the list" law, I have solved it:


The problem was more than one wacom device enabled in the input device 
list. If I only enable the "Pen stylus" device, everything seems to work 
perfectly (so far).


The confusion stemmed from the fact that when using xsetwacom I have to 
use the other devices ("Pad pad" and "Finger touch") to work with 
specific properties, so I assumed I needed to enable them in gimp to 
have them work there as well. Not the case.


Sorry to bother.

-c

On 04/06/2017 12:20 AM, Casey Connor wrote:
Hi -- I use three monitors. My wacom tablet works great, and I can 
also use my mouse to draw in the GIMP image window. When I try to map 
the tablet to a single screen (with my image window) it breaks the 
ability of the mouse to draw on the image.


Calling

xsetwacom --set "Wacom Intuos PT S 2 Pen stylus" MapToOutput next

...maps the tablet to the single screen appropriately, and the tablet 
continues to work great, but the mouse can no longer be used to draw 
on the image (it works fine for menus, tool windows, etc.) If I quit 
GIMP and restart it, the problem persists: tablet is fine, mouse is 
still broken for image editing.


If I unplug the tablet and plug it back in, everything works fine 
again, but the tablet is now mapped to all three screens again, and 
remapping it breaks the mouse again. If I MapToOutput before starting 
GIMP, it just breaks it at the start. Calling "MapToOutput next" 
repeatedly until the tablet is again mapped to all three screens also 
does not help: once it breaks, only unplugging the tablet will reset 
the buggy state.


Tested with a fresh portable AppImage from pixls.us, and from the otto 
repository (commits 2224733 and 257a4ceb, respectively.) Kubuntu 
16.10, kernel 4.8.0-46-generic, xsetwacom 0.33.0, using a Wacom 
Intuous Art Pen & Touch Tablet (CTH-490).


Thanks for any thoughts! I will report it as a bug unless someone has 
some ideas that I can try to narrow things down a bit more. Happy to 
do any debugging that will help -- it's so very close to working! If I 
can solve this last puzzle piece it'll be amazing to do photo editing. 
:-)


-c

P.S. One last detail, in case it's helpful: as the mouse moves the 
cursor into the drawing window, it picks up the location and moves the 
brush outline to that location, but does not update it after that 
(until the next time it enters that window). Similarly, if I try to 
drag a guide from the ruler border, the indicator arrows (in the ruler 
bars) show that it is tracking the cursor location correctly, but no 
guides are dragging around, and none are created when the button is 
released. If I do the same with the tablet, it works fine and makes 
guides.



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: 
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

List archives: https://mail.gnome.org/archives/gimp-developer-list


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug reports that would be nice to see on the milestone 2.10 list

[Elle Stone]

Your wish is my command, she said responding to IRC!

A compact list:

* No LCH color pickers and no LCH Hue-Chroma tool 
(https://bugzilla.gnome.org/show_bug.cgi?id=749902)


* No Luminance blend mode 
(https://bugzilla.gnome.org/show_bug.cgi?id=753163).


* No easy way to make Curves and Levels adjustments on linear RGB 
(https://bugzilla.gnome.org/show_bug.cgi?id=757444)


* No obvious way to invert colors on linear RGB 
(https://bugzilla.gnome.org/show_bug.cgi?id=757686).


* No easy way to draw a gradient using linear RGB 
(https://bugzilla.gnome.org/show_bug.cgi?id=735897).


* No easy way to correctly decompose to LAB/LCH and then be able to drag 
layers back to the layer stack 
(https://bugzilla.gnome.org/show_bug.cgi?id=765178.


* No easy way to correctly extract LAB/LCH channels as layers 
(https://bugzilla.gnome.org/show_bug.cgi?id=755376).


Best,
Elle
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug found: Unified transform and perspectivetool fail silently when layer is hidden.

[Joseph Bupe]

>
> Most of us seem to agree on this.
>
>
 I agree with the general feeling here.

Also, the "you can drop dockable dialogs here" text should be done with.
It's not the only place one can put the dockable dialogs.

Cheer.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.

[C R]

>
>
>> You can currently kinda get around this by setting the "Image opacity"
>> in the Tool options palate for unified transform tool to less than 100%.
>> Unfortunately, unless you also change the "Opacity" field in the layer
>> palate, the untransformed layer B is still in the way.
>>
>
> Thanks! for the tip.


Glad to help! I've been reading through your awesome writeups on GIMP's
color systems.
Love the "Sad little colorspace" part. Poor HSV! ;)


>
>
>> Thus my proposal:
>>
>> hide/remove the untransformed version of layer B while the user is
>> transforming it, and set the default "Image opacity" for the transform
>> tool to 50% by default.
>> This would get layer B out of the way, and let you see translucently a
>> bit of what is under the transformation preview as well (layer A).
>>
>
> Your proposal sounds good to me. I have found the "untransformed" copy of
> the layer being transformed to be an absolute nuisance since the first time
> I tried to use a transform tool.
>

Most of us seem to agree on this. The only person I've ever seen that spoke
up for the current way it's handled is GNUTux, on GIMPchat. But the
reasoning behind it (seeing a transform in relation to the original) I've
never heard of any use case where that was an actual benefit. It's always a
pain in the rump. It's just something I've learned to live with, but I'd be
dancing if it went away. It regularly wastes loads of time, every single
time.


Reading Gez's post the gimp-gui-list (
> https://mail.gnome.org/archives/gimp-gui-list/2015-November/msg00049.html),
> that's also the same proposal?
>
>
Yes. Hehehe. You can see what career graphic designers think of the
implementation. It really, really needs to change, and if I had the coding
skills, I'd have done it long ago, even if it were just patching my own
version. I hate it that much! ;P

-C
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.

[Elle Stone]

On 12/09/2015 01:05 AM, Gez wrote:

I raised this subject in the UI mailing list a few days ago. In my
opinion, A should be the solution.

We need to discuss the usefulness of having the original layer during
transforms. In my experience, most of the times it's a hurdle, blocking
the context for the transform.
But I'm aware that in some cases users would need to compare the
transformed layer vs. the original.
I don't think it's a good idea to rule out that situation, but I'm
convinced that it's an exception, and more frequently users want the
original layer hidden.


Is this what you mean by "original layer"? If a layer stack has two 
layers, A and B, with B as the upper layer, and if a 
transform/rotate/etc tool is used on B, the "original layer" is layer B 
*before* the tranform, and the transformed layer is what B would look 
like if the transform were made using the current settings.


If I understand what you mean by "original layer", I don't need to see 
the original layer B. What I really do need to see is layer A, meaning 
I'd like the option to set the opacity of the transformed layer B to 50% 
so I can compare the transformed layer B to layer A.


Unfortunately right now lowering the opacity of layer B on which the 
transform is being done doesn't seem to allow to see layer A through the 
*transformed* layer B.


Elle

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.

[Elle Stone]

On 12/09/2015 12:33 PM, C R wrote:

Is this what you mean by "original layer"? If a layer stack has two
layers, A and B, with B as the upper layer, and if a
transform/rotate/etc tool is used on B, the "original layer" is
layer B *before* the tranform, and the transformed layer is what B
would look like if the transform were made using the current

settings.


Unfortunately right now lowering the opacity of layer B on which the
transform is being done doesn't seem to allow to see layer A through
the *transformed* layer B.


You can currently kinda get around this by setting the "Image opacity"
in the Tool options palate for unified transform tool to less than 100%.
Unfortunately, unless you also change the "Opacity" field in the layer
palate, the untransformed layer B is still in the way.


Thanks! for the tip.



Thus my proposal:

hide/remove the untransformed version of layer B while the user is
transforming it, and set the default "Image opacity" for the transform
tool to 50% by default.
This would get layer B out of the way, and let you see translucently a
bit of what is under the transformation preview as well (layer A).


Your proposal sounds good to me. I have found the "untransformed" copy 
of the layer being transformed to be an absolute nuisance since the 
first time I tried to use a transform tool.


Reading Gez's post the gimp-gui-list 
(https://mail.gnome.org/archives/gimp-gui-list/2015-November/msg00049.html), 
that's also the same proposal?


Elle

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.

[C R]

>
> Is this what you mean by "original layer"? If a layer stack has two
> layers, A and B, with B as the upper layer, and if a transform/rotate/etc
> tool is used on B, the "original layer" is layer B *before* the tranform,
> and the transformed layer is what B would look like if the transform were
> made using the current settings.
>

Yes, Elle, I think you got it. :)

If I understand what you mean by "original layer", I don't need to see the
> original layer B. What I really do need to see is layer A, meaning I'd like
> the option to set the opacity of the transformed layer B to 50% so I can
> compare the transformed layer B to layer A.
>
> Unfortunately right now lowering the opacity of layer B on which the
> transform is being done doesn't seem to allow to see layer A through the
> *transformed* layer B.


You can currently kinda get around this by setting the "Image opacity" in
the Tool options palate for unified transform tool to less than 100%.
Unfortunately, unless you also change the "Opacity" field in the layer
palate, the untransformed layer B is still in the way.

Thus my proposal:

hide/remove the untransformed version of layer B while the user is
transforming it, and set the default "Image opacity" for the transform tool
to 50% by default.
This would get layer B out of the way, and let you see translucently a bit
of what is under the transformation preview as well (layer A).

-C


>
>
> Elle
>
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.

[C R]

One solution that involves keeping the original untransformed are:
add checkbox "show original" in the transform tool menu.
I still recommend that is is turned off by default, along with the "grid",
which also gets in the way of seeing the transform.

What I mainly use the perspective transform tool for is applying a screen
graphic to a powered-off device to make it look like it's turned on, so I
need to see what is behind it. I also perform minor perspective adjustments
to objects in photo collages to make them look like they were sitting next
to eachother. I have never found keeping the original there to be useful in
any way, which is why I suggest it be hidden by default. I also suggest
(while I'm suggesting things ;P), that the transparency of the
transformation preview be taken down to 75% opacity by default (though
keeping in changeable is good). This provides an even greater visibility to
what's underneath, so you can ensure you are not covering up essential
elements of what is underneath.

tldr: For me, context visibility is everything with the transform tool. I
always transform in relation to other layers, or the border of the image,
never in relation to the original, so I definitely agree with Gez on that.

-C


-C

On Wed, Dec 9, 2015 at 6:05 AM, Gez  wrote:

> El mar, 08-12-2015 a las 17:28 +, C R escribió:
> > In 2.8 it was possible to hide the layer you are transforming (with
> > perspective tool) to get the original out of the way during
> > transform.
> >
> > Proposed solutions:
> > A. Make the original hide automatically, making it unnecessary to
> > hide
> > the layer during transform.
> > B. Make sure the transformation is applied, regardless of the hidden
> > state of the layer.
>
> I raised this subject in the UI mailing list a few days ago. In my
> opinion, A should be the solution.
> B, applying a transform on a hidden layer, could be problematic. It's
> not a good idea to touch layers that are hidden, so preventing any tool
> from working on hidden layers is probably a good thing and all tools
> should be consistent doing so.
>
> We need to discuss the usefulness of having the original layer during
> transforms. In my experience, most of the times it's a hurdle, blocking
> the context for the transform.
> But I'm aware that in some cases users would need to compare the
> transformed layer vs. the original.
> I don't think it's a good idea to rule out that situation, but I'm
> convinced that it's an exception, and more frequently users want the
> original layer hidden.
>
> Does anyone have a different opinion on this one? I'm interested to
> know alternative workflows where that option is more useful than hiding
> the original layer.
>
> Gez.
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.

[Gez]

El mar, 08-12-2015 a las 17:28 +, C R escribió:
> In 2.8 it was possible to hide the layer you are transforming (with
> perspective tool) to get the original out of the way during
> transform.
> 
> Proposed solutions:
> A. Make the original hide automatically, making it unnecessary to
> hide
> the layer during transform.
> B. Make sure the transformation is applied, regardless of the hidden
> state of the layer.

I raised this subject in the UI mailing list a few days ago. In my
opinion, A should be the solution.
B, applying a transform on a hidden layer, could be problematic. It's
not a good idea to touch layers that are hidden, so preventing any tool
from working on hidden layers is probably a good thing and all tools
should be consistent doing so.

We need to discuss the usefulness of having the original layer during
transforms. In my experience, most of the times it's a hurdle, blocking
the context for the transform.
But I'm aware that in some cases users would need to compare the
transformed layer vs. the original.
I don't think it's a good idea to rule out that situation, but I'm
convinced that it's an exception, and more frequently users want the
original layer hidden.

Does anyone have a different opinion on this one? I'm interested to
know alternative workflows where that option is more useful than hiding
the original layer.

Gez.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Bug 719435

[Ofnuts]

On 12/02/2013 01:10 AM, Rick C. Hodgin wrote:

On 12/01/2013 12:15 PM, Ofnuts wrote:

On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote:
I was asked by Michael Natterer to discuss this enhancement on the 
GIMP developer list.

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

Basically, I'd like to see the line cue for the Pen tool colorized 
when either of the two X,Y axis offsets are 0, or when their 
absolute values are equal (or have it match the existing angles used 
for snapping, though I personally only use the 45 degree angle 
setting often).


This colorization cue would be visible without activating snapping, 
and would simply change the line color when those conditions are met.


I have no other reason for wanting it except that I think it is 
difficult to see when the line is at exactly 45 degrees since it 
uses such a smooth anti-aliasing algorithm, and that it would 
provide added value, be a nice helpful feature, and something that 
I've wanted in GIMP for quite some time. :-)


How would that be better than the current constrained angles?


It would cue automatically without constraining.  As the cursor moves 
around, the colors would indicate alignments.  It could be used to 
examine existing image content, or to help align new.


First,  unless we introduce some error margin the cue could be rather 
elusive because you would have to be on the right pixel (and stay there).


Second, I don't see the logic of checking if you are at 45° and not draw 
the line in a paint tool. If you want to check alignments, the right 
tool would be the Measure tool. Having display changes (color or else, 
there are color-blind users) on some angles (and perhaps distances) 
could be useful there (one more Tool option, and with the caveat about 
elusiveness). And as a reminder, the Measure tool also has constrained 
angles (so you can move the second measure point along an accurate 
vertical/horizontal/diagonal), and will let you to position H/V/H+V 
guides where the cursor is. So using both capabilities together you can 
easily define some point at 45° from an existing point(*)


(*) Note to the devs: Currently using the constrained angles disables 
snapping to guides and path.  Having both together would be useful: draw 
the perpendicular to a line through a given point, etc...


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 719435

[Hodgin, Rick C.]

On 2013-12-02 03:36, Ofnuts wrote:

On 12/02/2013 01:10 AM, Rick C. Hodgin wrote:

On 12/01/2013 12:15 PM, Ofnuts wrote:

On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote:
I was asked by Michael Natterer to discuss this enhancement on the 
GIMP developer list.

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

Basically, I'd like to see the line cue for the Pen tool colorized 
when either of the two X,Y axis offsets are 0, or when their 
absolute values are equal (or have it match the existing angles used 
for snapping, though I personally only use the 45 degree angle 
setting often).


This colorization cue would be visible without activating snapping, 
and would simply change the line color when those conditions are 
met.


I have no other reason for wanting it except that I think it is 
difficult to see when the line is at exactly 45 degrees since it 
uses such a smooth anti-aliasing algorithm, and that it would 
provide added value, be a nice helpful feature, and something that 
I've wanted in GIMP for quite some time. :-)


How would that be better than the current constrained angles?


It would cue automatically without constraining.  As the cursor moves 
around, the colors would indicate alignments.  It could be used to 
examine existing image content, or to help align new.


First,  unless we introduce some error margin the cue could be rather
elusive because you would have to be on the right pixel (and stay
there).

Second, I don't see the logic of checking if you are at 45° and not
draw the line in a paint tool. If you want to check alignments, the
right tool would be the Measure tool. Having display changes (color or
else, there are color-blind users) on some angles (and perhaps
distances) could be useful there (one more Tool option, and with the
caveat about elusiveness). And as a reminder, the Measure tool also
has constrained angles (so you can move the second measure point along
an accurate vertical/horizontal/diagonal), and will let you to
position H/V/H+V guides where the cursor is. So using both
capabilities together you can easily define some point at 45° from an
existing point(*)

(*) Note to the devs: Currently using the constrained angles disables
snapping to guides and path.  Having both together would be useful:
draw the perpendicular to a line through a given point, etc...


First, ofnuts, if you're the one who decides whether or not a new 
feature is included, I hereby withdraw my request and will cease all 
further input into GIMP.


Second, it would be while you're on the correct pixel only. If using 
fractional pixels (floans), then whenever integer rounding places you on 
that pixel it would highlight.


Third, it's for while you're already doing something on the image using 
that tool.  The cue would provide useful information from time to time, 
for very little additional programming as the line cure must already 
redraw itself as the mouse moves.  A simple test when rendering onto the 
output window and you're there.


Forth, as for changing the color, make it an option that must be enabled 
and let the user decide their own color. Or, make it a non color feature 
-- such as an alternating white/black dotted line cue on a 250ms timer.  
Lots of possibilities.


Best regards,
Rick C. Hodgin

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 719435

[Ofnuts]

On 12/02/2013 06:45 PM, Hodgin, Rick C. wrote:

On 2013-12-02 03:36, Ofnuts wrote:

On 12/02/2013 01:10 AM, Rick C. Hodgin wrote:

On 12/01/2013 12:15 PM, Ofnuts wrote:

On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote:
I was asked by Michael Natterer to discuss this enhancement on the 
GIMP developer list.

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

Basically, I'd like to see the line cue for the Pen tool colorized 
when either of the two X,Y axis offsets are 0, or when their 
absolute values are equal (or have it match the existing angles 
used for snapping, though I personally only use the 45 degree 
angle setting often).


This colorization cue would be visible without activating 
snapping, and would simply change the line color when those 
conditions are met.


I have no other reason for wanting it except that I think it is 
difficult to see when the line is at exactly 45 degrees since it 
uses such a smooth anti-aliasing algorithm, and that it would 
provide added value, be a nice helpful feature, and something that 
I've wanted in GIMP for quite some time. :-)


How would that be better than the current constrained angles?


It would cue automatically without constraining.  As the cursor 
moves around, the colors would indicate alignments.  It could be 
used to examine existing image content, or to help align new.


First,  unless we introduce some error margin the cue could be rather
elusive because you would have to be on the right pixel (and stay
there).

Second, I don't see the logic of checking if you are at 45° and not
draw the line in a paint tool. If you want to check alignments, the
right tool would be the Measure tool. Having display changes (color or
else, there are color-blind users) on some angles (and perhaps
distances) could be useful there (one more Tool option, and with the
caveat about elusiveness). And as a reminder, the Measure tool also
has constrained angles (so you can move the second measure point along
an accurate vertical/horizontal/diagonal), and will let you to
position H/V/H+V guides where the cursor is. So using both
capabilities together you can easily define some point at 45° from an
existing point(*)

(*) Note to the devs: Currently using the constrained angles disables
snapping to guides and path.  Having both together would be useful:
draw the perpendicular to a line through a given point, etc...


First, ofnuts, if you're the one who decides whether or not a new 
feature is included, I hereby withdraw my request and will cease all 
further input into GIMP.


I don't decide anything here.  Gimp development is an ergocracy. Those 
who work decide. I can at best voice an opinion.


Here, I'm merely answering your call for discussion. I'm sorry I'm the 
only one to answer that call. And discussion is not automatic approval.




Second, it would be while you're on the correct pixel only. If using 
fractional pixels (floans), then whenever integer rounding places you 
on that pixel it would highlight.


Third, it's for while you're already doing something on the image 
using that tool.  The cue would provide useful information from time 
to time, for very little additional programming as the line cure must 
already redraw itself as the mouse moves.  A simple test when 
rendering onto the output window and you're there.


The SMOP is in the eye of the feature requester :)

I still don't understand what you gain by knowing if your latest mouse 
movement puts you on a diagonal, versus just asking Gimp to put you 
there when you need it (constrained angles). And even more so on the 
paint tools, where the line indicates where the stroke will be.


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 719435

[Ofnuts]

On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote:
I was asked by Michael Natterer to discuss this enhancement on the 
GIMP developer list.

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

Basically, I'd like to see the line cue for the Pen tool colorized 
when either of the two X,Y axis offsets are 0, or when their absolute 
values are equal (or have it match the existing angles used for 
snapping, though I personally only use the 45 degree angle setting 
often).


This colorization cue would be visible without activating snapping, 
and would simply change the line color when those conditions are met.


I have no other reason for wanting it except that I think it is 
difficult to see when the line is at exactly 45 degrees since it uses 
such a smooth anti-aliasing algorithm, and that it would provide added 
value, be a nice helpful feature, and something that I've wanted in 
GIMP for quite some time. :-)


How would that be better than the current constrained angles?
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 719435

[Rick C. Hodgin]

On 12/01/2013 12:15 PM, Ofnuts wrote:

On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote:
I was asked by Michael Natterer to discuss this enhancement on the 
GIMP developer list.

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

Basically, I'd like to see the line cue for the Pen tool colorized 
when either of the two X,Y axis offsets are 0, or when their absolute 
values are equal (or have it match the existing angles used for 
snapping, though I personally only use the 45 degree angle setting 
often).


This colorization cue would be visible without activating snapping, 
and would simply change the line color when those conditions are met.


I have no other reason for wanting it except that I think it is 
difficult to see when the line is at exactly 45 degrees since it uses 
such a smooth anti-aliasing algorithm, and that it would provide 
added value, be a nice helpful feature, and something that I've 
wanted in GIMP for quite some time. :-)


How would that be better than the current constrained angles?


It would cue automatically without constraining.  As the cursor moves 
around, the colors would indicate alignments.  It could be used to 
examine existing image content, or to help align new.


Best regards,
Rick C. Hodgin

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug report for ID64917

[Mukund Sivaraman]

Hi Sashi

On Thu, Apr 04, 2013 at 05:24:34PM +0530, Sashi Kumar wrote:
 This is the bug report for https://bugzilla.gnome.org/show_bug.cgi?id=649172

I'm going to commit the patch in comment #7 (modified from the patch in
comment #2) and push it. Thank you for reviewing the patch.

Two things you can do:

* An unrelated crash happens when alt= is present in a map file,
  during load. Can you check what causes it and propose a fix?

* Please propose a fix for UTF-8 un-escaping.

Mukund


pgpb4ziMuVVhU.pgp
Description: PGP signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug report for ID64917

[Mukund Sivaraman]

On Thu, Apr 11, 2013 at 02:04:19PM +0530, Mukund Sivaraman wrote:
 Two things you can do:
 
 * An unrelated crash happens when alt= is present in a map file,
   during load. Can you check what causes it and propose a fix?
 
 * Please propose a fix for UTF-8 un-escaping.

One more thing:

* Do the other parsers (NCSA and CERN) also need unescaping?

Please can you check and make patches for these? You can open new bugs
for these to track them.

Mukund


pgp8q_P034JUj.pgp
Description: PGP signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug report for ID64917

[Sashi Kumar]

 Two things you can do:
 
  * An unrelated crash happens when alt= is present in a map file,
during load. Can you check what causes it and propose a fix?


Yeah, I already started working on it. It is due to double free. This crash
can be avoided if MALLOC_CHECK_ environment variable is set to 0. But
anyhow I will try to produce a fix in the code for this.



  * Please propose a fix for UTF-8 un-escaping.


I will start that soon.


 One more thing:

 * Do the other parsers (NCSA and CERN) also need unescaping?


 Please can you check and make patches for these? You can open new bugs
 for these to track them.


As far as I checked till now, they don't need unescaping because they don't
write the HTML encodings. CSIM only needs unescaping.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug report for ID64917

[Mukund Sivaraman]

Hi Sashi

On Thu, Apr 11, 2013 at 04:24:29PM +0530, Sashi Kumar wrote:
  Two things you can do:
  
   * An unrelated crash happens when alt= is present in a map file,
 during load. Can you check what causes it and propose a fix?
 
 Yeah, I already started working on it. It is due to double free. This crash
 can be avoided if MALLOC_CHECK_ environment variable is set to 0. But
 anyhow I will try to produce a fix in the code for this.

As you probably understand too, updating MALLOC_CHECK_ is neither a fix
nor a workaround. :)

The checking exists to catch such errors, and updating this environment
variable will only turn off the checking, but it will not stop the buggy
code from being executed.

   * Please propose a fix for UTF-8 un-escaping.
 
 I will start that soon.

Nod.

  One more thing:
 
  * Do the other parsers (NCSA and CERN) also need unescaping?
 
 As far as I checked till now, they don't need unescaping because they don't
 write the HTML encodings. CSIM only needs unescaping.

Super. Thank you for checking. :)

Mukund


pgplMlMTYUJ_H.pgp
Description: PGP signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug report for ID64917

[Sashi Kumar]

   Two things you can do:
   
* An unrelated crash happens when alt= is present in a map file,
  during load. Can you check what causes it and propose a fix?
 
  Yeah, I already started working on it. It is due to double free. This
 crash
  can be avoided if MALLOC_CHECK_ environment variable is set to 0. But
  anyhow I will try to produce a fix in the code for this.

 As you probably understand too, updating MALLOC_CHECK_ is neither a fix
 nor a workaround. :)

 The checking exists to catch such errors, and updating this environment
 variable will only turn off the checking, but it will not stop the buggy
 code from being executed.


That's right :) I will try to fix :)


* Please propose a fix for UTF-8 un-escaping.
 
  I will start that soon.

 Nod.

   One more thing:
  
   * Do the other parsers (NCSA and CERN) also need unescaping?
 
  As far as I checked till now, they don't need unescaping because they
 don't
  write the HTML encodings. CSIM only needs unescaping.

 Super. Thank you for checking. :)


yw :)
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 690089

[Chris Mohler]

On Sun, Mar 17, 2013 at 12:33 PM, Michael Haseler mich...@haseler.net wrote:
 As I predicted, someone has yet again decided that because GIMP doesn't
 destroy their work and makes gimp unuseable =by people like me


  isn't a bug.

 It is ... but I cannot see how to change the status back to its proper
 status which is a critical show stopper for users who have xmp metadata.

You should post to the gimp-devel mailing list instead of emails all
of those individual email addresses.

The bug you filed is almost certainly a duplicate:
https://bugzilla.gnome.org/show_bug.cgi?id=629044
https://bugzilla.gnome.org/show_bug.cgi?id=620552

Furthermore, when and where have you made this prediction?

Chris

PS - post any replies to the list, not to me.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 690089

[Michael Schumacher]

On 17.03.2013 18:43, Chris Mohler wrote:

On Sun, Mar 17, 2013 at 12:33 PM, Michael Haseler mich...@haseler.net wrote:

As I predicted, someone has yet again decided that because GIMP doesn't
destroy their work and makes gimp unuseable =by people like me


 isn't a bug.


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

No. I set it to incomplete, using the Bugzilla stock text:


   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||INCOMPLETE

--- Comment #6 from Michael Schumacher schum...@gmx.de 2013-03-17 
13:49:31 UTC ---
Closing this bug report as no further information has been provided. 
Please feel free to reopen this bug if you can provide the information 
asked for.

Thanks!


The bug you filed is almost certainly a duplicate:
https://bugzilla.gnome.org/show_bug.cgi?id=629044
https://bugzilla.gnome.org/show_bug.cgi?id=620552


Or maybe
https://bugzilla.gnome.org/show_bug.cgi?id=56443


Mike says that no emails were sent (up to the point when the bug status 
change probably triggered one). This can happen if mails on comments to 
bugs are disabled in one's email settings.


So everyone who's ever reported bugs in GNOME Bugzilla, please go to

https://bugzilla.gnome.org/userprefs.cgi?tab=email

and make sure that you receive mails for important updates, like new 
comments.



--
Regards,
Michael
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug with image moving

[gfxuser]

Siarhei Kuchuk wrote:
When Edit image, then paste other image, press M, movement is detected 
but image cannot be moved. 

Hi,

sounds like you either chose the wrong tool or the wrong object to move.
I checked it with 2.6.12 and 2.8. Both work fine.
First: pressing big M (in the English version) will start the Measure 
tool, which is different from the move tool. To use the move tool, press 
m without the shift key.
Second: in the move tool check which of three little imagebuttons behind 
the word 'move' is toggled. To move the latest pasted image (which is in 
a floating selection layer), the button 'layer' has to be toggled and 
the floating selection layer must be the active layer.


Best regards,

grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Paul Geraskin]

Hi! Thanks for answering.

 I agreed about interpolation. But as I said in my video 3dCoat is 
fully compatible with PHOTOSHOP. So, Overlay method works exactly as in 
photoshop, because it's a standard of CG industry.

 You already did this with GEGK too. But I cannot save Gegl image. :(
I cannot merge layers with Gegl interpolation and I cannot save to 
PNG/JPG with Gegl interpolation. This is the main problem.



I did another comparison with photoshop and Gimp:
http://i.imgur.com/qdesF.png



On 04/04/2012 04:11 AM, gespert...@gmail.com wrote:
2012/4/3 Paul Geraskin paul_geras...@mail.ru 
mailto:paul_geras...@mail.ru


Hi!

I found a bug with Overlay and Gegl:


I don't think it's a bug.
As far as I can tell, that's because the 3D program where you created 
your multilayered file does layer blending in linear space and GIMP 
with GEGL off does it in gamma-corrected space.
When use GEGL is selected, GIMP does the layer blending in linear 
space too, then you get similar results in both applications.
Some blending modes like overlay look very different in linear and 
non-linear space.

I'm not 100% sure, but it looks exactly like that.


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Paul Geraskin]

Also, the problem is only with Overlay Method. Multyply, Screen, Dodge, 
SoftLight, HardLight etc... works ok with Gegl and without Gegl. I 
showed it on the video.


So, the problem is only with Overlay.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Paul Geraskin]

Here is my PSD Test file you can take:

http://dl.dropbox.com/u/26887202/123/3dcoat/goat.psd
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Przemyslaw Golab]

Note: Overlay in Legacy mode works exactly like Soft Light, if that helps.

-- 
n-pigeon
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Michael Natterer]

On Wed, 2012-04-04 at 13:22 +0400, Paul Geraskin wrote:
 Thanks.
At present, I cannot use Overlay for my 3d production. This is the 
 most usable method. I just want to know will you be able to fix it in 
 Gimp 2.8? Overlay without Gegl should be like in Photoshop too.
 
Or is there any way to export/apply Gegl ColorManagement?

On a general note, *nothing* in GIMP should be like in Photoshop.
Most of us don't have Photoshop, or even an operating system
where it would run on, and it's not our goal to imitate anything.

Regards,
--Mitch

 On 04/04/2012 01:12 PM, Przemyslaw Golab wrote:
  Note: Overlay in Legacy mode works exactly like Soft Light, if that helps.
 
  -- 
  n-pigeon
 
 
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gimp-developer-list


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Paul Geraskin]

I have no photoshop too. I'm a Linux user. I use Gimp about 7 years for 
CG(Computer Graphics). But you can try VirtualBox(WinXP) and 
http://thepiratebay.se/torrent/4985377/Adobe_Photoshop_CS3_Portable for 
testing if you need it.


If we talk about CG, so there are some standards in many CG programs 
based on Photoshop. As I mentioned previously, you already made Overlay 
with Gegl. It works ok, but I cannot save to file (png/jpg/...) with 
Gegl color Management. And it's not possible to merge layers with Gegl 
color management too. As I mentioned it in video.


Is it possible to add saving to file with Gegl Color Management if 
View-Use Gegl is switched on?



On 04/04/2012 06:03 PM, Michael Natterer wrote:

On Wed, 2012-04-04 at 13:22 +0400, Paul Geraskin wrote:

Thanks.
At present, I cannot use Overlay for my 3d production. This is the
most usable method. I just want to know will you be able to fix it in
Gimp 2.8? Overlay without Gegl should be like in Photoshop too.

Or is there any way to export/apply Gegl ColorManagement?

On a general note, *nothing* in GIMP should be like in Photoshop.
Most of us don't have Photoshop, or even an operating system
where it would run on, and it's not our goal to imitate anything.

Regards,
--Mitch







___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Alexandre Prokoudine]

On Wed, Apr 4, 2012 at 6:23 PM, Paul Geraskin wrote:

 Is it possible to add saving to file with Gegl Color Management if
 View-Use Gegl is switched on?

Future v2.10 (currently goat-invasion branch) already saves XCF with
GEGL's data structure.

Alexandre Prokoudine
http://libregraphicsworld.org
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[gespert...@gmail.com]

2012/4/4 Paul Geraskin paul_geras...@mail.ru

 I have no photoshop too. I'm a Linux user. I use Gimp about 7 years for
 CG(Computer Graphics). But you can try VirtualBox(WinXP) and
 http://thepiratebay.se/torrent/4985377/Adobe_Photoshop_CS3_Portable for
 testing if you need it.


I don't think it's appropriate to link to copies of commercial software
here. This is not a warez forum.
It's also pointless. Developers aren't looking at Photoshop because they
can't get a copy. They aren't because they don't want to.
GIMP is not photoshop and there is no need to copy it.


 If we talk about CG, so there are some standards in many CG programs based
 on Photoshop. As I mentioned previously, you already made Overlay with
 Gegl. It works ok, but I cannot save to file (png/jpg/...) with Gegl color
 Management. And it's not possible to merge layers with Gegl color
 management too. As I mentioned it in video.


That's not correct. Industry standard aren't based on Photoshop. The
results are similar because they use the same principles (high bit depth,
compositing in linear space, color management).
It's true that GIMP before GEGL was somewhat disconnected with some high
end standards but that's planned to change when GIMP runs completely on
GEGL.


 Is it possible to add saving to file with Gegl Color Management if
 View-Use Gegl is switched on?


Forget the rest, this looks like a reasonable feature request: bake the
GEGL projection into the saved file.
That would be nice and solve your problems, right?
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Paul Geraskin]

Forget the rest, this looks like a reasonable feature request: bake 
the GEGL projection into the saved file.

That would be nice and solve your problems, right?



That's right! That's all I need. Photoshop will suck if you add this 
feature. :)

I just need to save all Layers with GEGL projection to jpg/png.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[Paul Geraskin]

OMG!

It works! Thank you all Guys!

Layer-New From Visible works pretty good. But I hope it will be 
supported by exporters too in future.


GOD BLESS GIMP DEVELOPERS
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] bug with Overlay

[gespert...@gmail.com]

2012/4/3 Paul Geraskin paul_geras...@mail.ru

 Hi!

 I found a bug with Overlay and Gegl:


I don't think it's a bug.
As far as I can tell, that's because the 3D program where you created your
multilayered file does layer blending in linear space and GIMP with GEGL
off does it in gamma-corrected space.
When use GEGL is selected, GIMP does the layer blending in linear space
too, then you get similar results in both applications.
Some blending modes like overlay look very different in linear and
non-linear space.
I'm not 100% sure, but it looks exactly like that.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 658610 patch

[Michael Natterer]

On Fri, 2012-02-10 at 22:13 +0200, Ville Sokk wrote:
 I posted a patch/diff for bug 658610
 (https://bugzilla.gnome.org/show_bug.cgi?id=658610). I thought
 Bugzilla sent out an e-mail but no one has replied so I'm posting
 here. Sorry if this is redundant. I would like to know if it is
 acceptable or if there's anything I could do better.

That is only because we suck, and you are a bit impatient :)

The patch will be reviewed soon.

--mitch


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 155733 - discussion of approach (bug: need to check return values of gimp_drawable_mask_bounds())

[Neil]

Bump..? Any core devs able to comment pls?

On Mon, Jan 9, 2012 at 11:30 PM, Neil neildev...@gmail.com wrote:

 Have looked some more at the various patches in the bugzilla list.

 After extra scrutiny of Luidnel's patch (9b6c9e1), I now realise that this
 is the very patch where Michael Natterer comments at the top that he has
 altered it so as to not spit messages, but the patch then makes iwarp.c
 do precisely that. I am now suspecting that iwarp.c got missed while the
 patch was being edited... :-)  Correct?

 In comment 26 (https://bugzilla.gnome.org/show_bug.cgi?id=155733#c26),
 Michael says that gimpressionist *should* warn, as it's interactive-only.
 But what does interactive-only mean? I initially took it to mean that if
 you tried to repeat it would bring back up the dialog box. Gimpressionist
 doesn't do that though - it simply reapplies the same effect to a new
 selection each time you repeat. In contrast, iwarp would fit my concept
 of what interactive-only means, as if you try to repeat, it *does*
 bring up the dialog box, so it seems that it really can't ever function
 without a dialog box.

 I've also noticed that a whole bunch of plugins do issue a g_message()
 before they bail out (including I think all of the ones patched by Bill
 Skaggs).

 So... I could use some guidance from core devs here (i.e. the people
 who'll be accepting/rejecting any patches). My own preference would
 certainly be for all plugins to issue a warning (in the form of a
 g_message() call or even a dialog) if they are about to do nothing because
 _mask_intersect() returns false. But if there is some argument against this
 we should patch the rest to stop doing it for consistency.

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 155733 - discussion of approach (bug: need to check return values of gimp_drawable_mask_bounds())

[Neil]

Have looked some more at the various patches in the bugzilla list.

After extra scrutiny of Luidnel's patch (9b6c9e1), I now realise that this
is the very patch where Michael Natterer comments at the top that he has
altered it so as to not spit messages, but the patch then makes iwarp.c
do precisely that. I am now suspecting that iwarp.c got missed while the
patch was being edited... :-)  Correct?

In comment 26 (https://bugzilla.gnome.org/show_bug.cgi?id=155733#c26),
Michael says that gimpressionist *should* warn, as it's interactive-only.
But what does interactive-only mean? I initially took it to mean that if
you tried to repeat it would bring back up the dialog box. Gimpressionist
doesn't do that though - it simply reapplies the same effect to a new
selection each time you repeat. In contrast, iwarp would fit my concept
of what interactive-only means, as if you try to repeat, it *does*
bring up the dialog box, so it seems that it really can't ever function
without a dialog box.

I've also noticed that a whole bunch of plugins do issue a g_message()
before they bail out (including I think all of the ones patched by Bill
Skaggs).

So... I could use some guidance from core devs here (i.e. the people who'll
be accepting/rejecting any patches). My own preference would certainly be
for all plugins to issue a warning (in the form of a g_message() call or
even a dialog) if they are about to do nothing because _mask_intersect()
returns false. But if there is some argument against this we should patch
the rest to stop doing it for consistency.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 155733 - discussion of approach (bug: need to check return values of gimp_drawable_mask_bounds())

[gg]

On 01/03/12 01:09, Neil wrote:

Hi...
Am just getting started with gimp hacking, and decided to pick a
gnome-love bug to have a look at :)

I have a fairly clear idea of how to fix plugins which don't have any
dialog box - they should just basically do nothing at all, and exit
silently. (I'd have thought they ought to take the first opportunity to
exit; I'm not sure this is true of the already-fixed ones but that's not
the current issue.)

For plugins with dialog boxes, things are less obvious. I chose grid
to look at first. I could change it in the fashion suggested in the
bugzilla discussion, so that instead of calling
gimp_drawable_mask_bounds() it calls gimp_drawable_mask_intersect() and
checks the return value. However, this would still run the dialog, with
a (totally spurious) preview. To me, it would make far more sense to
bail out before the dialog is even called. However, when I had a look at
blur_gauss.c, which is already fixed (i.e. it calls
gimp_drawable_mask_intersect()), I saw that it does allow the plugin
dialog to run.
In contrast, iwarp bails out immediately, with a warning that the
affected region is empty (in a status bar below the image window).

I was tempted to infer that blur_gauss was fixed in a really minimalist
way (just to avoid nasty stuff happening, e.g. crashes) while leaving
the code in a slightly icky state (i.e. the dialog box running even
though it can't do anything at all to the image), while iwarp was fixed
in a better way. However, when I look at the git commit attributed to
Luidnel Maignan (9b6c9e1fe4f46d2d47c6d97d4147cf060abd07f8) I can see
that *both* approaches were used (iwarp was fixed in this patch, and a
bunch of others too). So I'm confused!

Some guidance on which approach is best (and why) would be welcome...

ta
Neil


_


Correction to my last comment, I just checked and sharpen does seem to 
work but blur has no dialog , it just does a blur with an uncontrolled 
radius.


The ensuing Reshow Blur had nothing to reshow and just adds another 
uncontrolled blur.


:?



___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 155733 - discussion of approach (bug: need to check return values of gimp_drawable_mask_bounds())

[gg]

On 01/03/12 01:09, Neil wrote:

Hi...
Am just getting started with gimp hacking, and decided to pick a
gnome-love bug to have a look at :)

I have a fairly clear idea of how to fix plugins which don't have any
dialog box - they should just basically do nothing at all, and exit
silently. (I'd have thought they ought to take the first opportunity to
exit; I'm not sure this is true of the already-fixed ones but that's not
the current issue.)

For plugins with dialog boxes, things are less obvious. I chose grid
to look at first. I could change it in the fashion suggested in the
bugzilla discussion, so that instead of calling
gimp_drawable_mask_bounds() it calls gimp_drawable_mask_intersect() and
checks the return value. However, this would still run the dialog, with
a (totally spurious) preview. To me, it would make far more sense to
bail out before the dialog is even called. However, when I had a look at
blur_gauss.c, which is already fixed (i.e. it calls
gimp_drawable_mask_intersect()), I saw that it does allow the plugin
dialog to run.
In contrast, iwarp bails out immediately, with a warning that the
affected region is empty (in a status bar below the image window).

I was tempted to infer that blur_gauss was fixed in a really minimalist
way (just to avoid nasty stuff happening, e.g. crashes) while leaving
the code in a slightly icky state (i.e. the dialog box running even
though it can't do anything at all to the image), while iwarp was fixed
in a better way. However, when I look at the git commit attributed to
Luidnel Maignan (9b6c9e1fe4f46d2d47c6d97d4147cf060abd07f8) I can see
that *both* approaches were used (iwarp was fixed in this patch, and a
bunch of others too). So I'm confused!

Some guidance on which approach is best (and why) would be welcome...

ta
Neil


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list


I seem to recall posting to this list , a couple of weeks back that 
Enhance | Sharpen was effectively not doing anything , maybe this one 
has been fixed as well ??


/gg

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 155733 - discussion of approach (bug: need to check return values of gimp_drawable_mask_bounds())

[Neil]

On Tue, Jan 3, 2012 at 12:01 PM, g...@catking.net wrote:

 Correction to my last comment, I just checked and sharpen does seem to
 work but blur has no dialog , it just does a blur with an uncontrolled
 radius.

 The ensuing Reshow Blur had nothing to reshow and just adds another
 uncontrolled blur.

 :?


Yeah, this is entirely normal and as intended (I believe). The clue is in
the lack of ... after the name of the filter in the menu. E.g., the
gaussian blur does have a dialog in which you can set options, and so its
name is Gaussian blur..., as against just plain Blur.
Note though that my email (and this bug) is specifically about the special
case where the active layer is smaller than the image and the selection
doesn't overlap with it at all.

Neil
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 155733 - discussion of approach (bug: need to check return values of gimp_drawable_mask_bounds())

[Neil]

On Tue, Jan 3, 2012 at 2:09 PM, g...@catking.net wrote:

 My original comment about sharpen not working seems to have been a local
 problem, that is now fixed. I thought this may be relevant to your issue.


Yeah, it could have been. I tried to reproduce it before I read your second
message :)


 If blur does not have a dialog it must be a one size fits all and may as
 well be removed! It clearly is not properly integrated into GIMP if it gets
 listed as reshow when it was never shown.

 My earlier bug report here on sharpen showed it got integrated into menu
 as both reshow and redo even when I cancelled without doing a change.

 These are more like UI defects but I thought it may have something to do
 with dialogue failures not exiting cleanly or at the right time. I could
 not imagine someone adding a blur that was not adjustable, that's just dumb.


I tend to agree that the reshow/redo behaviour feels like a UI
bug/misfeature but I'm a novice here - others may feel differently (?).
And I was also caught by surprise recently by the blur behaviour - I had
thought it had a dialog box but perhaps I have always used one of the other
blurs (which does)... Perhaps it's there as a simple tool for beginners?

Neil
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug 312800: Selective gaussian blur should be able to read delta and blur from different sources

[Karthikeyan S]

Final Patch.
Changed the mmx code to use the another layer than the current one for
getting delta.

Please review.
If this is a useless patch since the request was too long ago, let me know.

-Karthik

On Thu, Dec 15, 2011 at 10:18 PM, Karthikeyan S karthikde...@gmail.comwrote:

 By suggested above I mean @
 https://bugzilla.gnome.org/show_bug.cgi?id=312800


 On Thu, Dec 15, 2011 at 10:16 PM, Karthikeyan S karthikde...@gmail.comwrote:

 I took the patch given earlier by Luis de* and
 made the changes suggested above along with code for updating preview.

 Attaching the patch. This currently does not work on mmx since we totally

 ignore the delta layer when calling mmx routine. But doesn;t break mmx.

 Working on mmx code changes...

 -karthik



From dd101f228b3798ad42eaeed242d160c4f4170a26 Mon Sep 17 00:00:00 2001
From: Karthikeyan S karthikde...@gmail.com
Date: Mon, 19 Dec 2011 21:49:32 +0530
Subject: [PATCH] Bug 312800: Selective gaussian delta from another layer

New combo box in the selective gaussian filter dialog box.
This combo box lets you select the layer to be used for delta
values.
---
 plug-ins/common/blur-gauss-selective.c |  160 +++-
 1 files changed, 115 insertions(+), 45 deletions(-)

diff --git a/plug-ins/common/blur-gauss-selective.c b/plug-ins/common/blur-gauss-selective.c
index 1d589c9..0d88733 100644
--- a/plug-ins/common/blur-gauss-selective.c
+++ b/plug-ins/common/blur-gauss-selective.c
@@ -53,6 +53,7 @@ typedef struct
 {
   gdouble  radius;
   gint maxdelta;
+  gint deltalayer_id;
 } BlurValues;
 
 
@@ -71,6 +72,8 @@ static void  sel_gauss(GimpDrawable *drawable,
 static gboolean  sel_gauss_dialog (GimpDrawable *drawable);
 static void  preview_update   (GimpPreview  *preview);
 
+static void  dialog_deltalayer_callback (GtkWidget *widget,
+ GimpPreview   *preview);
 
 const GimpPlugInInfo PLUG_IN_INFO =
 {
@@ -83,7 +86,8 @@ const GimpPlugInInfo PLUG_IN_INFO =
 static BlurValues bvals =
 {
   5.0, /* radius   */
-  50   /* maxdelta */
+  50,   /* maxdelta */
+  -1   /* delta layer id */
 };
 
 MAIN ()
@@ -161,12 +165,20 @@ run (const gchar  *name,
 
 case GIMP_RUN_NONINTERACTIVE:
   /* Make sure all the arguments are there! */
-  if (nparams != 5)
+  if (nparams != 5  nparams != 6)
 status = GIMP_PDB_CALLING_ERROR;
   if (status == GIMP_PDB_SUCCESS)
 {
   bvals.radius   = param[3].data.d_float;
   bvals.maxdelta = CLAMP (param[4].data.d_int32, 0, 255);
+  if (nparams == 5)
+  {
+bvals.deltalayer_id = param[2].data.d_drawable;
+  }
+  else
+  {
+bvals.deltalayer_id = param[5].data.d_drawable;
+  }
 
   if (bvals.radius = 0.0)
 status = GIMP_PDB_CALLING_ERROR;
@@ -216,6 +228,15 @@ run (const gchar  *name,
   values[0].data.d_status = status;
 }
 
+static void
+dialog_deltalayer_callback (GtkWidget   *widget,
+ GimpPreview *preview)
+{
+  gimp_int_combo_box_get_active (GIMP_INT_COMBO_BOX (widget),
+ bvals.deltalayer_id);
+  gimp_preview_invalidate (preview);
+}
+
 static gboolean
 sel_gauss_dialog (GimpDrawable *drawable)
 {
@@ -226,6 +247,7 @@ sel_gauss_dialog (GimpDrawable *drawable)
   GtkWidget *spinbutton;
   GtkObject *adj;
   gboolean   run;
+  GtkWidget *deltalayer_id;
 
   gimp_ui_init (PLUG_IN_BINARY, FALSE);
 
@@ -259,7 +281,7 @@ sel_gauss_dialog (GimpDrawable *drawable)
 G_CALLBACK (preview_update),
 NULL);
 
-  table = gtk_table_new (2, 3, FALSE);
+  table = gtk_table_new (3, 3, FALSE);
   gtk_table_set_col_spacings (GTK_TABLE (table), 6);
   gtk_table_set_row_spacings (GTK_TABLE (table), 6);
   gtk_box_pack_start (GTK_BOX (main_vbox), table, FALSE, FALSE, 0);
@@ -290,6 +312,15 @@ sel_gauss_dialog (GimpDrawable *drawable)
 G_CALLBACK (gimp_preview_invalidate),
 preview);
 
+  deltalayer_id = gimp_layer_combo_box_new (NULL, NULL);
+  /* Default delta layer: The layer that is being blurred */
+  bvals.deltalayer_id = drawable-drawable_id;
+  gimp_int_combo_box_connect (GIMP_INT_COMBO_BOX(deltalayer_id), bvals.deltalayer_id,
+  G_CALLBACK (dialog_deltalayer_callback), preview);
+  gimp_table_attach_aligned (GTK_TABLE (table), 0, 2,
+ _(Delta Layer:), 0.0, 0.0,
+ deltalayer_id, 4, TRUE);
+
   gtk_widget_show (dialog);
 
   run = (gimp_dialog_run (GIMP_DIALOG (dialog)) == GTK_RESPONSE_OK);
@@ -323,6 +354,7 @@ init_matrix (gdouble  radius,
 static ALWAYS_INLINE void
 matrixmult_mmx (const guchar  *src,
 guchar*dest,
+guchar*del,
 gint   width,
 gint   height,
 const 

Re: [Gimp-developer] Bug 312800: Selective gaussian blur should be able to read delta and blur from different sources

[Karthikeyan S]

By suggested above I mean @
https://bugzilla.gnome.org/show_bug.cgi?id=312800

On Thu, Dec 15, 2011 at 10:16 PM, Karthikeyan S karthikde...@gmail.comwrote:

 I took the patch given earlier by Luis de* and
 made the changes suggested above along with code for updating preview.

 Attaching the patch. This currently does not work on mmx since we totally

 ignore the delta layer when calling mmx routine. But doesn;t break mmx.

 Working on mmx code changes...

 -karthik


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list