[Gimp-user] image alignment/registration

[Casey Connor]

Hi - I was curious what the best overall image alignment plugin/method 
in GIMP (or out of GIMP) was these days?


"Best" for me means "most powerful/flexible/option-rich".

I've come across the hugin align_image_stack, the G'MIC plugin's "Align 
layers" option, and the image registration plugin 
. (I've also used the "Exact 
Aligner" script, but it's two layers only.)


The goal is to align and then use mean/median for noise reduction 
stacking. I'll probably be working in 16bit.


Do all three methods do sub-pixel alignment? I read someone on pixls.us 
suggesting that the user upscale the source images by up to 1.33x before 
aligning for the sake of effectively achieving sub-pixel alignment, but 
if the current alignment methods do that anyway, seems like I should 
skip it... ?


Thanks!

-c


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

Re: [Gimp-user] 32bit float image opens white?

[Casey Connor]

Well, I'll be darned if I can make it happen now. It happened about 40 
times in a row, I got the example all ready, it happened with that as 
expected, uploaded it, sent the message to the list, and it magically 
never happens. Rebooted, still doesn't happen. Also doesn't happen with 
all the images I was seeing it with yesterday.


I did nothing at all in gimp except open the test images and convert 
between precisions. E.g. no changing of settings or moving of windows or 
doing anything else in the OS in general. The "perceptual gamma" vs 
"linear light" setting was probably the only thing that changed, but 
nothing I do with it now seems to make the bug come back.


Tried after removing my .gimp*/ and .config/GIMP directories, no change.

So... Nevermind, I guess? :-) I'll let you know if I see it again. It's 
just weird that it happened repeatedly and predictably over a couple 
days, and then it suddenly stops... the magic of asking the mailing 
list, I suppose. :-)


-c

On 02/06/2017 11:32 AM, gimp-user-list@gnome.org wrote:
Ack, hold on, it suddenly started working somehow, even after 
repeatedly not working as I prepared that email... stand by...


On 02/06/2017 11:29 AM, Casey Connor wrote:



Is it possible to get hold of this image to test it?


Sure, here's one -- http://lacinato.com/pub/gimp/wilber_median.tif

It happens on any image; and it turns out it's not just white, it's 
some kind of clipped version of the image, apparently. Changing to 
any floating point format doesn't help; changing to an integer format 
makes it appear correctly. Note that the layer thumbnail appears 
correctly (presumably it's converted to an integer format when 
generated.)


How I made and checked the image:

$ wget https://www.gimp.org/images/frontpage/wilber-big.png
$ gmic -median_files w\*.png -o wilber_median.tif
$ identify wilber_median.tif
wilber_median.tif TIFF 300x224 300x224+0+0 32-bit sRGB 1.077MB 0.000u 
0:00.000

$ gimp wilber_median.tif

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




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

Re: [Gimp-user] 32bit float image opens white?

[Casey Connor]

Is it possible to get hold of this image to test it?


Sure, here's one -- http://lacinato.com/pub/gimp/wilber_median.tif

It happens on any image; and it turns out it's not just white, it's some 
kind of clipped version of the image, apparently. Changing to any 
floating point format doesn't help; changing to an integer format makes 
it appear correctly. Note that the layer thumbnail appears correctly 
(presumably it's converted to an integer format when generated.)


How I made and checked the image:

$ wget https://www.gimp.org/images/frontpage/wilber-big.png
$ gmic -median_files w\*.png -o wilber_median.tif
$ identify wilber_median.tif
wilber_median.tif TIFF 300x224 300x224+0+0 32-bit sRGB 1.077MB 0.000u 
0:00.000

$ gimp wilber_median.tif

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

[Gimp-user] 32bit float image opens white?

[Casey Connor]

I just calculated a median image from a stack using gmic 2.0.0 on the 
CLI. Worked fine, and the result image is 32bit float:


$ identify downstream_hi_median.tif
myfile.tif TIFF 3456x5184 3456x5184+0+0 32-bit sRGB 286.7MB 0.000u 0:00.000

When I open it in gimp (2.9.5 -- commit c175afbc) it opens as all-white. 
The layer preview thumbnail is fine, though, and changing precision to 
16bit integer the image appears correctly.


Is this bug known to anyone? I couldn't google anything up on it.

Thanks!

-c


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

Re: [Gimp-user] GEGL - run C2g batch in command line

[Casey Connor]

Sorry to derail -- but this piqued my interest in c2g -- where can one 
find it in recent GIMPs? It's not in the Tools->GEGL menu... (I'm on 
otto-kesselgulasch-gimp-edge PPA).


Thanks,
-c

On 01/23/2017 01:55 AM, waldauf wrote:

Hello folks!

Is there some way how to run Tools/GEGL/C2G convertion in command line like
batch?

For example - I have 10 pictures which I want to convert with some params. This
conversion takes a lot of time when you have to load picture into Gimp, set C2G
params and convert. I would like to convert it trough night like batch


Thx for your advice in advance.

Waldauf



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

Re: [Gimp-user] version 2.9.4 for Windows 10

[Casey Connor]

One issue is that http://www.partha.com is mistakenly redirecting to 
http*s*://*www.www*.partha.com


-c


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

[Gimp-user] speeding up gimp

[Casey Connor]

I've been googling for info on making GIMP faster, and I think I have 
most of the bases covered (caches, SSD, RAM, etc.), but using large 
brushes on large images is still very slow.


I have an i7 4770K and am using Intel on-board graphics. Would getting a 
graphics card of some kind be likely to improve things? I can't seem to 
find clear info -- it sounds like the latest GIMPs support GPU 
acceleration, but I'm not clear on whether I'd see a difference with my 
hardware?


I'm using 2.9.5 (on Kubuntu).

Thanks for any tips.

-c


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

Re: [Gimp-user] speeding up gimp

[Casey Connor]

Thanks Joel --


I've been googling for info on making GIMP faster, and I think I have most
of the bases covered (caches, SSD, RAM, etc.), but using large brushes on
large images is still very slow.

Any reason you have to use such large brushes?

Except, I should ask first, how large to you mean?


Just convenience, I suppose -- I'm just doing photo editing, often in 
16bit precision, with transparency, multiple layers, etc. The images are 
~5100x3400, brushes around 770 pixel diameter. (I know it's a lot to ask 
of the program, and I'm not surprised that it's slow.)


This is when e.g. painting in shadows with a slow flow rate with the 
airbrush or paintbrush, or painting layer masks through complex 
selections (e.g. after making a series of luminosity masks and deriving 
selections from those). It's often nice to have big soft brushes to do 
this: small brushes would take way too much time. And more speed would 
help the brushes not be so stepped as I move them around.



I have an i7 4770K and am using Intel on-board graphics. Would getting a
graphics card of some kind be likely to improve things? I can't seem to find
clear info -- it sounds like the latest GIMPs support GPU acceleration, but
I'm not clear on whether I'd see a difference with my hardware?

Depends on the card. Some cards are better supported by free software
drivers than others, due in no small part to the manufacturers
attitudes towards free software and towards good design.


Thanks -- I am aware of that dynamic. In the past I was looking at a 
used GTX 750 Ti or 950 for the sake of speeding up Blender, but some 
folks advised me that the speedup would be negligible at that price 
tier. I was just wondering how much the operations I was doing 
(described above) would actually be GPU-accelerated, and if they were, 
if the difference would be significant, given that I already had a 
reasonably recent CPU.



I'm using 2.9.5 (on Kubuntu).

KDE desktop? What other libraries?


Yes -- KDE. And sorry -- what sorts of libraries are you asking about? 
Currently it's a pretty vanilla installation (roughly equivalent to 
Ubuntu 16.10 with KDE); I am using the i915 Intel driver. Compositing is 
enabled (and disabling it has no effect on speed). GIMP is 2.9.5 commit 
a774b24 from otto-kesselgulasch PPA.


Thanks for the help,
-c

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

Re: [Gimp-user] Add frozen object from short exposure frame to long exposure frame

[Casey Connor]

stationary artificiallighting is provided from the people who work at these 
caves as well).So my plan is to use my Rokinon 12mm f2.0 with my Sony A6000 on 
a tripod and setit to max aperture and long exposure, with maybe ISO of about 
400 to 800. Dothose settings sound about right to get some good low-lit cave 
pictures?


For the long exposure, use the lowest native ISO your camera has (don't 
use any "extended" ISO values your camera might offer.) There is nothing 
to be gained by going to 400 or 800 except a shorter exposure time 
(which can be relevant, but in your case sounds like it isn't). For the 
fast one, I'd use the widest aperture the lens has, the longest shutter 
speed you can afford given the motion you want to capture, and then set 
the minimal ISO to get the exposure.



Wouldthere be any reason to lower the aperture?


There might be -- if you have the luxury of a tripod and long exposures, 
you can narrow the aperture either to get better sharpness from the lens 
(most, but not all, will be sharpest a couple stops up from the widest 
aperture -- you can research the lens online; unfortunately dxomark.com 
doesn't cover that lens), or to get more depth of field. f2 is going to 
be pretty shallow. Might be cool, might not.


You might look into image averaging (usually taking the median, 
actually, as opposed to the mean)... I was just experimenting with a 
GIMP workflow for that and it's pretty great. It's useful for taking 
low-light pictures without a tripod, especially if you want to use 
higher shutter speeds.


You also might think about longer focal length lenses. I love 12mm, and 
that's what I would take first in your situation, but if any of the 
geometry of the caves allows for farther shots (i don't know how big 
they are), you can use the telephoto effect to enlarge the background... 
it can be a neat effect 
. 
Also, if you don't have many options of where to set up for a shot, e.g. 
because you're straddling a stream and balancing on a boulder or 
whatever, having a zoom gives some flexibility.


-c

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

Re: [Gimp-user] Switch back and forth between tools

[Casey Connor]

I'm in support.

I think this is discussed here: 
https://bugzilla.gnome.org/show_bug.cgi?id=373060


...some activity ~10 months ago... maybe someone will find some time to 
look at it. Looks like just some quick cleanup work on the proposed 
patch is needed?


-c

On 02/18/2017 10:00 AM, 2ward2 wrote:

I'd like to see a keyboard shortcut that could switch instantly between the
current tool and the last tool used. For example, between the paintbrush and the
smudging tool or any other choice, but then return immediately to the paintbrush
when the key was pressed again. I suppose a work-around would be to re-program
two keys that lie close together for the tools one wanted to use, but my idea
would simply recall the last tool used and call it up when the key was pressed.
At that point the new "last tool used" would be the one that was just replaced.
Anyone else favor this idea?



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

[Gimp-user] no more crashing

[Casey Connor]

Latest gimp from otto-kesselgulasch repo seems to work fine with gmic! 
Thanks! -c



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

[Gimp-user] gmic with otto repo not working?

[Casey Connor]

Hi there -- just updated from Otto Meier's repo to 2.9.5 (36ebe03) and 
can't seem to get GMIC filters to work anymore -- most of them crash 
(e.g. most of those in the "Details" submenu). This is on Ubuntu 
(Kubuntu 16.10).


I upgraded gmic to 2.0.0 from gmic.eu and the problem remains. Tried 
with a fresh .config/GIMP and same thing.


Anyone else seeing this? I'll report a bug to GMIC, but I thought I'd 
ask here in case anyone had a workaround... can't live without GMIC. :-)


Thanks!

-c


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

Re: [Gimp-user] gmic with otto repo not working?

[Casey Connor]

Another note, in case it helps: I've been trying to get a working 
version of gimp/gmic on my machine just so I can get some stuff done, 
and I can't seem to do so, which had me wondering if the issue was due 
to some interaction of Kubuntu with gmic.


I tried a few of the AppImages from pixls.us, and I tried my normal 
install with the latest gmic (2.0.0 pre-release) installed. Nothing 
worked. Even the AppImages that pre-dated my problem by months (gmic 
1.7.5, etc) still didn't work. Some of them worked slightly better, but 
then I would free-select a region and run gmic and get the same crash.


I have a Kubuntu VM I'm going to experiment with a little and I'll let 
you know if I find anything interesting.


Incidentally, I also tried the recent Win 8.1 version from Partha 
(portable 'standard' version), and that also crashed. I just can't win. :-)


(More details on everything I've tried here: 
https://github.com/dtschump/gmic-community/issues/67 )


-c

On 01/18/2017 11:55 AM, Thorsten Stettin wrote:

Am 18.01.2017 um 20:41 schrieb Thorsten Stettin:

Ok, the problem seems to be a segmentation fault. Is any fucking good 
debugging guru out there? :-(



Am 18.01.2017 um 20:27 schrieb gimp-user-list@gnome.org:
That's a relief! I've trying really hard to come up with a way for 
David T to reproduce it and couldn't. Good to know I'm not alone.


I'm not familiar with your work -- are you maintaining the Otto 
Meier repo? Or GMIC? 

Yes, I'm the maintainer.
Just wondering how I should fix my problems once you have worked 
your magic. :-)

For now I'm completely mystified. I'll do my very best.


Thanks for looking into it!
-Casey

No thanks, it's a question of honour. :-D


I upgraded gmic to 2.0.0 from gmic.eu and the problem remains. 
Tried with a fresh .config/GIMP and same thing.


Anyone else seeing this? I'll report a bug to GMIC, but I thought 
I'd ask here in case anyone had a workaround... can't live without 
GMIC. :-)
Oops! The last time I was building G'MIC was at  2016-12-24. The 
version is 1.8.0_pre.
I could reproduce that strange behavior. My environment is like 
yours: Kubuntu 16.10, Gimp 2.9.5 (36ebe03), G'MIC 2.0.0, all 64bit.
I see: G'MIC 1.8.0_pre chrashes as well. I will build new Gimp 
packages. Shit! :'(










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


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

Re: [Gimp-user] color management -- basic question

[Casey Connor]

I recommend using Rec2020 or ACEScg as your "go to" wide gamut color 
space (but not when using default GIMP, for reasons already mentioned) 
- ACEScg is used by people making images for cinema, Rec2020 is the 
up-and-coming standard for monitors, and both of these spaces are good 
all-around editing color spaces.


Thanks, I'll check those out. Unfortunately my raw development program 
(Canon DPP) only exports to a few options.


Profiling your monitor is a good thing to do. If your monitor is 
relatively new and has a good sRGB preset, then what you see right now 
is probably a pretty good guide to what your images actually look 
like. But not all monitors come with good sRGB presets.


Yeah, it's old and cheap (Dell 1707Fp). :-) I had planned to use 
Argyll/displaycal, and make a matrix profile per your suggestions. I 
think I read on your site that a LUT version would also be handy also 
for using occasional perceptual rendering intent to get a feel for all 
the detail in an image?


So currently trying to soft proof to the built-in GIMP sRGB profile is 
a waste of time as LCMS soft proofing will report that all the colors 
are in gamut.


Hmmm... so if I have a wide-gamut image and set soft-proofing profile to 
sRGB-elle-V4-srgbtrc.icc, soft proofing works -- that's because your 
version of gimp's sRGB is amended in the necessary ways to make it so?


I think you might mean "layer blend modes"? - "overlay" is the name of 
a particular blend mode, but it's not one of the LCH blend modes.


Yes, thanks.

Well, what you can do is duplicate the layer, use GIMP's 
"Colors/Levels" or "Colors/Curves" or "Colors/Exposure" and set the 
layer blend mode to "Lightness", which will leave the Hue and Chroma 
of the original layer unaltered.


Nice! I had previously used the Lch blend modes for color repair stuff; 
hadn't played with the lightness mode.


Thanks once again,
-c

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

Re: [Gimp-user] color management -- basic question

[Casey Connor]

Thanks very much, Elle, for the detailed reply!

Firstly: I've been studying up on color theory for the last month or two 
and your website is amazing and very helpful, so thanks for the huge 
amount of work you have put in to it. There are not many (possibly no) 
resources like it, at least as far as I've found, for the color curious. 
We all owe a big debt of gratitude.


The only reason I was playing with the output profile and monitor 
profiles was mainly to test my understanding of it, not because I was 
developing a particular workflow.


The "colorful image" I was using was one of the test images here: 
http://joco.name/2014/03/02/all-rgb-colors-in-one-image/
I used one of the 4096x4096 8-bit-per-channel images, which I scaled to 
1024x1024 -- I just wanted an image to play with that I could be sure 
would show me a shift when/if it happened -- in other words, it's just a 
test image and I just assigned a randomly-chosen larger-than-sRGB gamut 
to it so I could see how the rendering intents looked --  so it has no 
associated color space, afaik, it's just "all the values" (or was, until 
I scaled it down.)


I now understand that with the generic sRGB profile I was using I 
shouldn't expect the rendering intents to look any different from each 
other.


Longer-term, I was interested to work in wider color spaces for the sake 
of photography. I'd just be exporting to Wide Gamut (or whatever larger 
space) and opening that up in gimp. The hope was to possibly retain some 
more detail, soft-proof to check what's out-of-gamut, experiment, and 
otherwise possibly get better results with certain transformations in 
Gimp. From what you said it sounds like the CCE is the version to use if 
I'm going to go through with that plan, since it amends certain tools to 
not assume sRGB under the hood, but maybe the default version of gimp 
would still be useful just to get a feel for what's out-of-gamut, and I 
could still use g'mic tools if they work in Lab/Lch/etc, right?


(Also, I hope to profile my monitor soon.)

There are many versions of the sRGB ICC profile 
(http://ninedegreesbelow.com/photography/srgb-profile-comparison.html). 
Most of these versions are matrix profiles. Where did you get the sRGB 
profile that you are using as the monitor profile, and what's its 
exact file name?


From color.org, I think, judging by metadata? Not actually sure where 
it came from -- sRGB_IEC61966-2-1_black_scaled.icc


But yeah, nothing carefully-chosen, whatever it is -- I did read up a 
bit on the variety of sRGB profiles (thanks again to your site) and I 
know that I shouldn't trust or use or speak to any of them before 
checking ninedegreesbelow.com. :-)


If you need ICC profiles, I provide a suite of well-behaved ICC 
profiles here: https://github.com/ellelstone/elles_icc_profiles - 
click the "Clone or download" button to download the zip file, just 
ignore the code folder (unless you feel like compiling your own set of 
profiles), and look in the "profiles" folder to find the already made 
ICC profiles. This profile: "sRGB-elle-V4-srgbtrc.icc" is exactly 
equivalent to the GIMP built-in sRGB profile.


I'm sorta curious why GIMP's built-in sRGB profile rarely appears in 
menu lists of available profiles -- e.g. the monitor profile choice, or 
the soft-proofing profile choices? I only see it when converting an 
image to a new color profile, and that makes me wonder if I'm still 
misunderstanding something fundamental about profile types.


I absolutely agree with you that LCH is amazing, and now that it's 
available, I can't imagine ever trying to edit without LCH. Default 
GIMP and CCE both provide the LCH blend modes. In addition CCE 
provides LCH color pickers and an LCH Hue-Chroma tool. So if even if 
you only ever edit sRGB images, you might find CCE worth using until 
these capabilities are added to default GIMP 2.9.


Yeah, those overlay modes are great (and thanks once again to your 
website for cluing me in to them). Are your LCH tools in the roadmap for 
2.9 or 2.10? That'd be super. I was about to file a FR for Lch mode in 
the native gimp levels dialog... is that already planned? (I've been 
using g'mic's colors->curves in Lch mode and it works great to boost 
shadows without altering colors.)


Thanks so much!
-c

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

Re: [Gimp-user] color management -- basic question

[Casey Connor]

Thanks again, Partha! As a recent convert to LCH, Elle's version looks 
pretty amazing. I'm a little nervous to mess with my gimp install, as a 
non-sysadmin expert, but if Elle has the time to respond maybe she can 
let me know if there'd be value in trying her version. (I get the 
impression from her page on the subject that 2.9.5 has all the same 
color management stuff in it that her version does.)


It's not at all crucial to my workflow that the rendering intent be 
obeyed, I was just curious what was going on, because I thought I 
understood it and the results seemed to imply that I didn't. I wasn't 
sure if this was a flaw in my thinking or gimp.


-c

On 01/08/2017 04:47 PM, Partha Bagchi wrote:
Try Elle Stone's color corrected experimental version. See if that 
helps. CCing her in case.


On Sun, Jan 8, 2017 at 6:37 PM, Casey Connor 
<gimp-user-l...@caseyconnor.org 
<mailto:gimp-user-l...@caseyconnor.org>> wrote:


Hi -- basic color management question here; this is gimp 2.9.5
(commit 00faf17965) on Linux.

If I open a colorful image and assign a ProPhoto profile to it,
the colors get blown out, as expected.

If I set the monitor profile to various color profiles, the colors
shift around, as expected.

If I set the monitor profile to sRGB, and then try all the various
rendering intents, the colors never change, which
surprises/confuses me.

My expectation was that since gimp is interpreting the colors of
the image as being in the ProPhoto space, and I've told it that
the monitor is in sRGB, changing the rendering intent should
change the displayed colors as it shifts them to be in-gamut for sRGB.

I understand (from the tooltip) that I shouldn't expect preceptual
vs. relative colorimetric to exhibit a difference, but shouldn't I
see a change with both saturation and absolute colorimetric?

Thanks for any help!

-c

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




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

[Gimp-user] boosting shadows

[Casey Connor]

Hi -- I was working on a 16bit tiff trying to boost shadows in gimp 
similar to how I do it in raw photo development software.


I was almost able to do it, but not well, because gimp doesn't provide 
much resolution in the low end of the histogram when adjusting curves, etc.


The best solution I found in gimp was to use gmic and enlarge the curve 
dialog across two monitors, which almost gave enough resolution to 
adjust as needed, but it was still a pain, and the results weren't as nice.


I ended up using rawtherapee semi-successfully (the controls for the 
curves are easier to adjust) but none of the solutions compared to using 
the raw software I normally use (Canon's Digital Photo Professional) 
because it uses some kind of scaled histogram (e.g. log scale on x axis).


Any techniques anyone knows to get this done in gimp? I know there are 
other methods with masks and overlays and such -- I haven't been too 
impressed with them and am hoping for some kind of curve tool... maybe a 
plugin? Thanks!


-c

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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

Then I take the resulting output.tif file, open it in gimp, change the
precision to 8 or 16bit, and remove the alpha channel (right-click the
layer). This is the result of that process:
http://caseyconnor.org/pub/image/aligned_and_medianed.tif

It certainly looks very good!
However, it's not clear after all, if you used gmic after align_stack or just
applied it directly to the original frames.


I did align_image_stack, and then applied gmic to the aligned frames.


I'm using the latest developing version, 2.9.something, and it already supports,
at least, 16-bit images. Not sure about 32-bit.


Yeah, it should work fine.

It's interesting to see that PS apparently handles lens distortion when 
aligning images -- those are impressive results. But maybe 
align_image_stack + gmic + gimp can work for you in some cases, too.


Good luck with it,
-c

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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

One last thought: if you are going to remove the barrel distortion in 
those images, you might try removing it before doing the image 
alignment... that might allow align_image_stack to work better... -c



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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

Ok -- I believe PS is beating align_image_stack because the picture 
seems to have been taken with a very wide lens (i.e. short focal length) 
from close up... as a result, there is a lot of barrel distortion, and 
in addition there is a lot of camera movement between frames, so the 
result is that the image distorts differently from frame to frame and 
align_image_stack is not able to do it automatically. Meaning, when you 
turn the camera that much, it "bends" the contents of the image in 
various different ways that make the images much harder to align. PS 
might be able to automatically correct for that distortion, but 
align_image_stack seems to struggle with it -- I get the same bad 
alignment results you did, but read on for more ideas:


If you can use a longer focal length and stand farther away, and also 
hold the camera more still, I think it will work better (and have less 
barrel distortion as well.) Your PS screenshot also looks like there was 
some kind of contrast or something applied (by PS, I assume? -- maybe 
related to the layer overlay mode when you stack the frames? -- or maybe 
PS is just doing a better job!)


But note this: you don't have to, and probably shouldn't, use the manual 
layer stacking method. That creates a simple averaging of the pixels, 
and it's probably pretty tedious to set up. There is another utility you 
can use to create the median, instead of the average (aka mean), of the 
image, which usually looks better. After I do align_image_stack, I use 
gmic  to take the median of the files. The command line 
looks like this (where test0001.tif etc are the images after alignment):


   gmic -median_files test\*.tif -o output.tif

(you have to use "\*" with wildcards in gmic for whatever reason.)

Then I take the resulting output.tif file, open it in gimp, change the 
precision to 8 or 16bit, and remove the alpha channel (right-click the 
layer). This is the result of that process: 
http://caseyconnor.org/pub/image/aligned_and_medianed.tif


I think it looks pretty good -- maybe not as nice as photoshop, but that 
may just be the "contrast" that PS seems to have added. Note how the 
median, as opposed to the mean, eliminates the most mis-aligned frames 
automatically: those bad frames are left in if you average/mean the 
frames. As mentioned, I think you can make it look a lot better by 
taking better original pictures.


Even if you use PS to align the images, you should look into using gmic 
to take the median, rather than stacking the layers. Just remember that 
gmic outputs 32bit-float RGBA images, and you'll usually want/need to 
convert those to something more common.


(Note: current stable releases of gimp don't support high-precision 
images -- not sure if they will open the 32bit out of gmic or not. I'm 
using 2.9.5.)


-c

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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

Did you try the -g option with align_image_stack? Or -t?

I align hand-held images with align_image_stack and it works fine, even 
without those options... e.g. this one: 
https://www.flickr.com/photos/lacinato/32628735771/in/dateposted-public/


-c

On 03/24/2017 12:58 PM, oneaty wrote:

Per recommendations here, I've used it and it worked really well; I've
read, and experienced, that it seems to need images to be pretty close

Thanks for the feedback.
I believe if I shoot with a tripod it would work fine.
The point is that a tripod isn't an option to me most of the time.
My only camera is an old point & shoot Canon A3100, boosted by CHDK. CHDK has
many wonderful features, but the one I mostly use is its raw capability, not
available on Canon original  firmware.
Besides, I usually do a lot of stacking, pushing the final image quality to its
limits.
And here is my problem.
With PS, I can auto align hand held shots with excellent results. The
differences in perspective between shots do exist but are not big, because I try
to hold the camera the most steadier I can when shooting.
I just came from aligning the same set of pictures in PS I tried in Hugin, and
it worked almost perfectly.
Before that, I had also tried using JImage (and its full package FiJi), but it
is really, really complex and I gave up.
So, unfortunately (being an open source fan), I will still have to keep with PS,
until I find an open source alternative to its auto alignment feature.




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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

Ah, ok. So what exactly goes wrong: one or two of the images is off-kilter?

If you specify -g, try using something besides the default, as I'm not 
sure that using the default will change the behavior. (Meaning, not 
specifying -g probably results in the same thing as just "-g" -- the 
documentation is a little unclear, but I assume it's active when not 
specified.) Perhaps try -g 3 or 4 instead? I'm not 100% sure how to 
interpret it. If that doesn't work, try 6 or 7?



Btw, what os are you using?


Kubuntu 16.10.

-c

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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

So, backing up a step: when you say align_image_stack doesn't work, what 
do you mean exactly? I assumed you meant that it did a poor job aligning 
the images, but I don't think the command lines you list there would 
even work to start the program, so I'm wondering now if you meant that 
it doesn't even run?


"-a" requires a prefix following it, and "-g" requires a number.

E.g.:

align_image_stack -a someprefix -g 8 *.tif

Documentation is here: http://wiki.panotools.org/Align_image_stack

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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

D'oh, the -d option! And -x -y -z sound promising as well. Not clear 
what -i does -- doesn't it always optimize the center shift? Or does 
"center shift" mean something more complex than simple x/y translation?


Thanks, Pat! Pays to RTFM. The hugin toolkit continues to amaze me.

That generates a result as good as photoshop for me, judging from the 
demo that oneaty posted. Good to learn how to better use this tool.


-c

On 03/29/2017 06:43 AM, Pat David wrote:

align_image_stack.exe -v -m -d -i -x -y -z -a aligned_ *.tif

Gave me pretty rock solid results with your .tif files:

https://transfer.sh/DgimG/oneaty.zip

pat

On Tue, Mar 28, 2017 at 3:03 PM oneaty  wrote:


Could I have another link to the images to test something?

Sure.

https://goo.gl/photos/GCoSg4uANxLGunDAA


--
oneaty (via www.gimpusers.com/forums)
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list



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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

So, by looking at the help text, it seems that you used all the options suited
to focus stacking.


At least in the help file I'm looking at, I think the only option "for" 
focus stacking is -m ? For lenses with focus breathing (i.e. almost all 
lenses) if you are changing the focus for each shot, that will have the 
effect of changing the FOV a little bit, and that option apparently 
enables correction for that effect. But it may also be useful if you 
happened to move forward/back a bit between shots (which isn't really 
the same as zooming, of course, but is similar). You could try not using 
-m and see if it makes a difference for your use.


-x -y and -z sound like they attempt to correct for moving around 
slightly when you take the picture (i.e. translational as opposed to 
rotational changes?)


-d sounds like it might compensate for distortion due to rotation (i.e. 
the distortion when you are close with a wide angle lens) but I'm just 
guessing. :-)


I think the lesson is that align_image_stack defaults to not applying 
most of the corrections, and if you want them, you have to enable them.


I wonder if --distortion would also be a smart thing to turn on.

-c

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

Re: [Gimp-user] image alignment/registration

[Casey Connor]

I tried

align_image_stack -a align -g 10 -t 5 *.tif


Did you try with a lower-than-default -g? E.g. "-g 3"?

If you want to upload the base .tif files somewhere, I can try to align 
them, so we can see if there is some strange difference between 
align_image_stack on our machines.


-c

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

[Gimp-user] image fit-to-window on open?

[Casey Connor]

I am surprised that I can't seem to google this, but:

How can I have GIMP fit the image to the window when it opens it?

Prefs -> Image Windows -> Initial zoom ration: "Show entire image" is 
selected, but neither shows the entire image nor fits it to the window. 
My camera images open at 25% zoom, which results cropping off the top 
and bottom of the window, and requiring a ctrl-shift-J on every opened 
image to be able to see it all.


(This is with 2.9.5, but it's been this way as long as I recall.)

Thanks!

-c


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

Re: [Gimp-user] Using rotary encoders etc.

[Casey Connor]

What I'd love to be able to easily do in GIMP, is to plug in, e.g. a control
surface like a Behringer BCR2000 (large number of rotary encoders), and
configure it so that I can change e.g. colours or brush sizes by twiddle knobs
on the controller.


YES! Hold the phone, though, have you seen this? 
https://www.gimp.org/unix/howtos/gimp-midi.html


Maybe it's not as simple as you were hoping for. (It's also an old page, 
not sure what the current state of affairs is.)



More generally, a way that I can send messages to GIMP from
anywhere to do things like changing brush size. From GIMP's end, all you really
need is a generic 'numerical event' functionality, and then separate daemons
which listen to other events, and send appropriate messages to GIMP.


Could GIMPs scripting interface be used in this way? I.e. could a third 
party whip up a go-between that translated MIDI events into python API 
calls, etc?


In this thread 
 
(2012) Alexandre Prkoudine says "We just need to patch GIMP to support 
JACK and Jack Session" -- it appears this stuff has been thought about. 
I've only googled searched for 30 seconds... but thanks for the idea. My 
tablet is not performing as I'd hoped (on linux, due to lack of OS 
support) so I'm looking for easy ways to change brush size, zoom, etc.


-c

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

[Gimp-user] problems with input controllers

[Casey Connor]

I got a wacom pen tablet and was working through setting it up with gimp 
on Kubuntu. (Wasn't particularly successful, but that's a different thread.)


Now my regular mouse is all misconfigured and I can't seem to fix 
things. E.g. ctrl-scrolling with the mousewheel to zoom in/out is 
broken. (Pen tablet is currently unplugged and system rebooted.)


If I wipe the profile dir, everything works again, but it seems like 
there are bugs that should be fixed here, so I'll report what's 
happening in case anyone has thoughts on how to fix it or what I may be 
doing wrong.


Most times (but not all) when I pull up preferences, the mouse clicks 
are ignored in that window. I have to use the keyboard to get the to 
Input Controllers configuration pane, and maybe 50% of the time the 
mouse will then work in that window. As I said, sometimes it all works fine.


With a fresh profile, I see "Main Mouse Wheel" and "Main Keyboard" on 
the right, and "Mouse Wheel" and "Keyboard" on the left (as an aside, I 
have no idea what the distinction between those two sets is supposed to 
be.) I can't find in any of the configurations where 
ctrl-scroll-up-on-the-mouse is associated with zooming in, but 
apparently it happens somewhere, because it works with this default profile.


With my regular profile, I see "Mouse Wheel" on both the "Available" and 
the "Active" list, which seems odd. "Keyboard" is in the available list, 
and "Main Keyboard" is in the active list. But no amount of 
configuration seems to matter. If I remove stuff from the "active" list, 
or configure it however, I can never zoom in with the mouse scroll 
wheel. Not to mention the intermittent inability to click in the 
preferences window.


Any ideas? Thanks!

This is 2.9.5, commit 86e101e, on Kubuntu linux.

-Casey


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

[Gimp-user] color managing slows gimp down?

[Casey Connor]

I notice that when I use a color managed display, the zooming in and out 
of an image is very slow (maybe 500ms per increment). If I disable color 
management, zooming is instantaneous.


Is this normal/expected?

Gimp 2.9.5, commit 86e101e322, Kubuntu 16.10.

Thanks,

-Casey

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

Re: [Gimp-user] GIMP resize options

[Casey Connor]

Do:


Image > Scale Image


And uncheck the "chain" icon next to the values. This is pretty standard 
GUI to indicate that things are not "linked". Same paradigm in play in 
the layers dock; they can be linked together so that they move together.


You can also use the Scale tool (ctrl-T by default, I believe.)

(I'm in 2.9.5 but I believe the above applies all the same.)

-c

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

[Gimp-user] troubles with 32bit float...

[Casey Connor]

I'm having lots of issues with the 32bit tiffs that come out of G'MIC 
CLI processing in Linux (Kubuntu 16.10 in my case).


They don't open properly in GIMP, or most any other software. There is 
clearly something going wrong somewhere, but I'm not sure where to file 
a report as I'm not sure where the root cause may be (GIMP, underlying 
tiff libraries, or G'MIC, etc.) If anyone has any insight, I'd 
appreciate it.


When I apply a -median_files filter with G'MIC, it generates a 32bit 
float file that opens as all-white in GIMP. But I can change the 
precision (in GIMP) from 32bit-float to any integer format, and the 
image suddenly appears and I can work with it just fine. Here is a 
demonstration image: http://caseyconnor.org/pub/image/32bitfloat.zip (145MB)


Can anyone reproduce that? I've asked here before without luck, but I've 
seen on other forums that I'm not the only one with this issue. (This 
happens in any recent version of GIMP on Linux or Windows for me, but 
most recently tested in otto-kesselgulasch repo commit 2944dbd.)


I tried to generate a smaller simple example starting with a 100x100 
pixel image, 16bit integer precision (same thing happens with 8bit): I 
make a simple gradient, save it to png or tif, process through G'MIC, 
and open the result in GIMP. Result: image is all white, and in this 
case changing precision does *not* make the real image appear -- I can't 
see the image no matter what I do. Here is a zip file with the original 
and the gmic processed version that won't open in GIMP: 
http://caseyconnor.org/pub/image/smallexample.zip


The KDE image viewer (gwenview) shows the image differently every time 
it opens it: sometimes a corrupted version, sometimes a line across a 
black background, and the line changes color every time the image is 
opened. (I mention this only in case it points at some system library 
issue.)


If I open the 32bit float G'MIC images in Hugin, they open fine, but the 
resulting 32bit float output from Hugin can not be opened in or 
processed by GIMP in linux or windows.


AN important note: I can open all of these images (post-G'MIC, big image 
or small 100x100 image) in Luminance HDR: it seems to have no trouble 
with them.


Any thoughts? Are there GIMP bugs here to be addressed? Can anyone 
reproduce this?


I've had some success using G'MIC in 16bit integer mode (by appending 
",ushort" to the file name); my main goal here is to sort these bugs out.


Thanks!


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

[Gimp-user] installing resynthesizer in 2.9.5?

[Casey Connor]

Hi -- what's the latest correct way to install resynthesizer in the 
2.9.5 nightly, if that's in fact possible?


The version here  did not work for 
me... ("/home/casey/.config/GIMP/2.9/plug-ins/resynthesizer: error while 
loading shared libraries: libgimpui-2.0.so.0: wrong ELF class: ELFCLASS64")


I tried to git clone and build it but ./autogen.sh doesn't work; it 
says: "configure: error: GIMP development libraries not found; please 
install." -- not sure what to install to correct that.


Any thoughts? Seems like it's possible since it's in the pixls.us 
AppImages? Thanks!


-c


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

Re: [Gimp-user] installing resynthesizer in 2.9.5?

[Casey Connor]

Just to close this thread -- when using the gimp-edge repo, installing 
resynthesizer via gimp-plugin-registry worked for me.


Thank you to the maintainers.

-c

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

Re: [Gimp-user] installing resynthesizer in 2.9.5?

[Casey Connor]

See the signature at the end of all mailing list messages for the 
unsubscribe link.


List managers: I'd like to re-suggest changing "List membership:" to 
"Unsubscribe from list:" or similar and moving it to the head of the 
list of links; especially for non-native english speakers maybe it would 
help cut down on the frequent requests for unsubscription?


-c


On 06/25/2017 10:42 AM, Sherlock Ohms wrote:

Please remove me from your mailing list. Thank you
C:-)


----
*From:* Casey Connor <gimp-user-l...@caseyconnor.org>
*To:* "gimp-user-list@gnome.org" <gimp-user-list@gnome.org>
*Sent:* Saturday, June 24, 2017 3:12 PM
*Subject:* Re: [Gimp-user] installing resynthesizer in 2.9.5?

Just to close this thread -- when using the gimp-edge repo, installing
resynthesizer via gimp-plugin-registry worked for me.

Thank you to the maintainers.

-c

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




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

Re: [Gimp-user] tips on working with gigantic files?

[Casey Connor]

Hey, just wanted to follow up on the gigapixel editing...

I tried the overcommit_memory thing, clearing undo history, making a big 
swap, changing tile size, etc. Nothing seemed to help with my particular 
image on my particular system, but I appreciate the tips. Guess I just 
need a lot more memory. :-)


I wasn't able to do any editing or adjustment on the image, since most 
tools would crash out the program, but I was able to stitch it all 
together in a mostly satisfying way by piecing it out and using montage. 
I then put it online using OpenSeadragon.


I think for now I will not work with such large images. It's just too 
painful. :-) But it's nice to have some tools to work with medium size 
stuff.


Thanks for the help!

-Casey

P.S. - Here's the pic, if anyone's interested: 
http://caseyconnor.org/pub/image/osd/nfalls/


Slightly edited (small) version is here 
.


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

Re: [Gimp-user] Double mails from the list ?

[Casey Connor]

I'm also seeing a lot of double posts. The headers between the 
duplicates are kind of mess; e.g. of the message you just sent, the 
first has the ntlworld DKIM signature, the second doesn't. The Received 
route indicate by the first seems to imply that a virginmedia.net server 
is re-injecting it? The second copy has a more logical Received chain, 
but no DKIM header.


I note also that the second copy has two gimp-user-list signatures at 
the end of the email body, implying accidental re-injection.


Sounds to me like a routing misconfiguration at gnome.org, which I guess 
was already obvious. :-)


-c

On 06/18/2017 05:00 PM, Ken Moffat wrote:

On Sun, Jun 18, 2017 at 04:26:14PM -0700, Ken Moffat wrote:

Or rather, I wrote it at 00:26:14 +0100 on Monday.  That post
appeared on the list, followed by a second version with West-Coast
American time.

I'd noticed one or two double-posts recently (I filter this list
into a mailbox with a lot of other lists, and traffic from this list
is mostly light).  But then _I_ double-post and so does the next
guy.

Anyone know what is going on ?

ĸen


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

[Gimp-user] Fwd: Gimp 2.9.4 windows installer

[Casey Connor]

Maybe try here: https://www.partha.com/

(scroll down and look on the right side of the page)

(That's for version 2.9.5.)



Gimp 2.9.4 has been out for a while now but nowhere can I find a link to a
64-bit windows installer for that release. I know it is unstable, but I 
would still like to play with it. I have version 2.9.2 which was/is 
hosted somewhere, but try as I might I run into walls for 2.9.4. Any 
links would be greatly appreciated.

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

[Gimp-user] G'MIC compatibility / Re: Gimp 2.9.4 windows installer

[Casey Connor]

my way again. I have installed 2.9.5 now and have run into g'mic problems with
gmic-gimp.exe causing an error on startup. I have removed gmic completely and
reinstalled it, but there must be an old reference floating about somewhere as I
can still not use it. Will do a complete reinstall of 2.9.5 and g'mic today
after a registry cleanout and see if that makes a difference.


I take it you are on Windows... I'm on Linux, but for whatever it's 
worth the only current 2.9.5 linux version of GIMP that I found that 
works with G'MIC is the http://pixls.us/files AppImage (AFAIK there are 
only AppImages for linux). The current otto-kesselgulasch GIMP version 
does not seem to work with GMIC. Thorsten S. was looking in to it, last 
I heard, and said that it was going to be non-trivial to fix. (Any 
update, Thorsten?)


The general picture I get is that things are in flux and maintaining 
G'MIC/GIMP compatibility is not easy as things evolve. Even the pixls.us 
AppImage only works for one invocation of G'MIC when dealing with large 
images. (My bug report is here 
.)


I don't know if this info is useful or at all related, but thought I'd 
mention it.


-c

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

Re: [Gimp-user] tips on working with gigantic files?

[Casey Connor]

I don't think this will solve the problem you described, but I have
found that clearing the undo history after every operation done on open
files frees a lot of memory in cases where there is /almost/ too much
data for the system to cope with.


Thanks, great tip -- As you say, I think it might not help here because 
I'm opening the file and immediately trying to export (i.e. no undo 
history) but that's great to keep in mind for the future.



Another possibility:  Crop the images you are trying to merge down to
just the bits that overlap, process those, then add the cropped parts
back in.


Ah! Yes! I don't think I can combine them in gimp (due to RAM), and I 
don't think I can even crop the image now (same RAM overflow issue) but 
I bet I can crop to the overlap areas, do the overlap, export that, and 
then combine the three sections (top, overlap, and bottom) with the 
"montage" command. Thanks for the insight!


@Ken & @Liam Re: swap -- I did try this with a 16GB swap enabled and it 
never seemed to swap; but I'll try it with overcommit enabled as Liam 
suggested (you implied that that will trigger GIMP to fork the PNG 
export?). Currently, when it maxes out on RAM, everything slows to a 
crawl; as in, moving the mouse causes the mouse to update its position 
once every few seconds; takes minutes just to move the mouse to the 
corner of the screen, etc. GUI interaction (e.g. trying to close a 
window or switch to a v-term) doesn't seem possible, no matter how long 
I wait. In other words, the system is brought to its knees. Is that what 
heavy swapping can look like, and what I should expect even if 
overcommit is enabled? I just want to know when I should let it go 
overnight and expect that it's slowly working through the file, and when 
it's actually just spinning wheels and not getting anything done...


I will also play with tile cache size and so forth (it has been at 8GB; 
undo history was also at 8GB, but again, I was just opening and then 
exporting...)


@Rick:

Just out of curiosity, why such a huge file? What do you intend to do 
with the finished product if you could get your computer to work (if 
you don't mind me asking)? 


Very fair question. :-) I just wanted to make a zoomable 'gigapixel' 
image for the heck of it. No true demand that it be so huge. Maybe I'll 
print it large-scale some day if it turns out well. For now I'm mainly 
just honing my skills on the techniques and learning what my computer 
can handle. (And the only reason it's sliced in two parts is that hugin 
can't write out the image in one piece without running out of RAM.)


Thanks, everyone, for the help,
-c

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

[Gimp-user] tips on working with gigantic files?

[Casey Connor]

Hi -- I'm trying to do some simple work on a 0.5GP image in GIMP 2.9.5 
(on Linux). (Image is ~23k by 22k pixels, 16bit RGBA).


I can open it fine, and it currently has two partial-canvas layers that 
are cross faded into each other (I'm manually stitching two slices of a 
big hugin panorama.)


The RAM is just about maxed -- I have 16GB, and it's enough to do some 
simple things to the image but I can't do much else.


I need to flatten the image into one layer so I can have a hope of doing 
further processing on it, but just having the image open puts it too 
close to the RAM limit to make that possible: I can't flatten the image, 
I can't export as PNG, etc. Whatever I try, the RAM soon maxes out and 
the system grinds to a halt, necessitating a hard power cycle.


I tried using 'convert' to convert the .xcf to PNG; no luck, as it 
doesn't work with 2.9.X XCF files. Maybe there is another route along 
these lines? (For some reason GIMP won't let me save as an older-version 
XCF, saying that the file is using incompatible features; not sure what: 
it's just two layers, one with a layer mask. The layers aren't full 
canvas size, maybe that's it?)


Any tricks I might be able to pull? Splitting out individual channels? 
Managing or virtualizing memory somehow? (I notice that my swap is never 
used -- not sure if it's misconfigured or if it's just not possible to 
use it in this case for whatever reason...) I don't care if the export 
procedure is slow, I just need to do it once to get the image down to a 
manageable size in RAM... maybe I could whip up a VM and give it tons of 
disk-backed virtual memory?


I tried all this on Windows, too (using a Partha GIMP) -- it actually 
exported something, but it was mostly black with bits of corrupt tiles 
here and there. Then I tried again with a larger tile cache and it 
crashed the OS and corrupted my bios somehow... yikes.


Unfortunately I can't afford more RAM.

Thanks for any ideas!

-c


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

Re: [Gimp-user] When black and white is not black and white

[Casey Connor]

I'll take a stab at this, but other more knowledgeable people may weigh 
in: as I understand color theory, the notion that there is a canonical 
equivalent grayscale value for every color is somewhat of a fallacy; any 
such translation relies on pyscho-perceptual assumptions about how we 
perceive different colors. As a result, translating from a color image 
to a B image is somewhat of an art (heavily informed by lots of research).


I'm not intimately familiar with the various algorithmic options in GIMP 
to do this conversion, but different options use different methods, as 
you seem to have found. I'm guessing, but: sliding the saturation to 
zero likely applies a standard transformation to go from RGB to HSV, 
then sets "V" to zero, and then translates back to RGB. This may involve 
different assumptions and techniques than "mode -> grayscale" which 
might do a more (or less) subtle transformation.


Here's another detailed link on the subject: 
https://patdavid.net/2012/11/getting-around-in-gimp-black-and-white.html


I'm fond of the "C2G" GEGL filter (which in the latest GIMP betas is 
under Colors -> Desaturate -> Color to Gray, but in older versions is 
apparently under Tools -> GEGL Operation (see the tutorial)), but it 
does a bit more than just convert the colors.


Also, a minor pedantic note: Colors -> Hue-Saturation -> 
slide-saturation-to-zero doesn't technically change the image to a 
grayscale image, as it's still an RGB image internally. And other exotic 
methods of making an image "black and white" might actually preserve 
some imperceptible amount of color information in the pixels to achieve 
the effect. (I think I've read about that, but can't cite anything off 
hand.)


-c

On 06/05/2017 09:02 PM, Lancer wrote:

I am a school teacher. One of the checks I ask students to do in order to test
the contrast of their graphics work, is to convert the images to grayscale and
see whether images are still clear.

There are two methods students are using to convert their images to grayscale
for this test...


Method 1: flatten image, then Colors > Hue-Saturation => slide the saturation
slider down to zero.
Method 2: image => mode => grayscale

Either of these methods results in a grayscale image, but the grays are not
exactly the same.

For example, if I have absolute red (#FF) next to blue, the grayscaled-blue
may match the grayscaled-red depending on the tone *and* the method used.
Method 1: Absolute red (#FF) will grayscale-match absolute blue (#FF)
Method 2: Absolute red (#FF) will grayscale-match a slightly lighter shade
of blue  (#2626FF)

Why are the two methods of grayscale having a different result? I would have
thought that conversion to grayscale would be the same process as dragging down
the saturation of an image.

...and given that they are different, which is the better method to use in terms
of testing for contrast in media assignments?



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

Re: [Gimp-user] TIF Layers

[Casey Connor]

Just to throw it out there into the universe: it would be great if GIMP 
offered an "open the analogous TIFF page for remaining files" 
checkbox... e.g. when I open 45 such TIFF's as layers I have to click 
through 45 dialogs to get the 'real' image for each layer. (One can of 
course automate this extraction with the command line as well.) Or a 
prefs setting to default to opening the largest page, or similar.


(It would also be great if Canon DPP had a "don't save thumbnail" on 
export, of course, but that's a different and much less helpful mailing 
list. :-) )


-c


On 06/13/2018 12:21 PM, BillyT wrote:

It is an embedded thumbnail image, used by some image management
applications to save loading that monster main image. Speeds
navigation up.

Ignore it. If you have it as a layer, you can safely delete the layer.
Otherwise do not open in the beginning. You can select the 'page' to
use in the Gimp tif import dialogue.

Thanks, Rich.



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

Re: [Gimp-user] TIF Layers

[Casey Connor]

It is also be for a different mailing list/forum, but there are good, 
free, and Gimpp-friendly alternatives to Canon DPP, such as 
RawTherapee or Darktable :-)


Thank you! Yes, I'm aware of and love (and use, and prefer) both of 
those programs... but DPP has the "digital lens optimizer" which seems 
to do some specific magic thing (presumably with proprietary/protected 
manufacturer knowledge of their lenses) that I can't seem to duplicate 
in other software (including lightroom, capture one, etc.). It's not 
always good to use it, but often it is. But I get closer every day to 
abandoning it.


Anyway, like you say, different mailing list. Thanks, -c

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

Re: [Gimp-user] Stuck in Brightness/Contrast Loop, etc.

[Casey Connor]

outlier opinion tangent: Tools which are accessed primarily via menu, 
and operate through a pop-up dialog box instead of on-canvas 
interaction, should not even be using the tools class. It is 
counter-intuitive to the new user that any dialog box -based operation 
has lingering side effects on their session after the operation has 
concluded. (compare plug-ins and scripts)


Agreed -- I've struggled to understand why e.g. Brightness/Contrast, 
which has no tool options anyway, opens a "tool options" mode in the 
tool box just so one can repeat it by clicking on the canvas. Doesn't 
seem useful, and is obviously confusing to new users. Perhaps it should 
follow the settings in prefs -> Interface -> Toolbox -> Tools Configuration.


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

Re: [Gimp-user] GIMP 2.10-RC1 Previews Loading Slowly

[Casey Connor]

Where did you download the GIMP 2.10 that you are testing?


After installing the program, I noticed it's running pretty slowly. Most menus
in the color menu are loading slowly but the most noticeable thing I'm noticing
is that it's taking anywhere from 10-12 seconds to load any preview for any
color adjustment.


The menus are loading slowly? Meaning, you click on "Colors" at the top 
of the screen, and the opening of the menu is not instant? Or did you 
mean that the dialog windows appear slowly once you have selected an 
option from the menu?



Now I'm definitely new so I don't know much about this, but is this normal for
2.10? I am editing TIF files around 155MB and am running v2.10 on my Lenovo
Y700. It's running Windows 10 with 16GB of RAM, Intel core i7 6700HQ @ 2.60GHZ
and a GTX 960M. The photos and GIMP are running off my SSD.


Not sure, but it sounds slow to me... I frequently edit ~90MB 16bit 
tiffs and the previews when adjusting color are around 1 second (desktop 
i7 4770K, 16GB RAM), so I'd expect yours to take on the order of 2-3 
seconds. If you want to upload a test image somewhere I'd be happy to 
poke at it.



  What I'm noticing,
however, is that during the sluggish performance, my task manager is showing my
cpu usage never reaches 50% and my RAM usage stays around 50%.


What are you disks doing during this period?


I have tried various fixes on the internet including increasing tile cache size
from 7 to 14 GB and increasing the undo memory. I have tried disabling color
management. None of these have worked to reduce or remove the sluggishness.


I have had issues with color management slowing things down, but you've 
already tried that. Have you tried disabling "Interface -> Enable layer 
& channel previews"? I'd be surprised if it fixed your issue, but when 
I've had complicated layering stuff going on, my memory is that it has 
helped. Wish I had other ideas for you...


-c

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

Re: [Gimp-user] 'critical error' running luminosity mask script

[Casey Connor]

Thanks --


starting the gimp from a term gives a series of failed assertions


Hmmm, all I got in stdout was

*WARNING* missing babl fast path(s): "R'G'B'A u8" to "B' u8"
*WARNING* missing babl fast path(s): "R'G'B'A u8" to "A u8"

...but anyway yeah I saw those failed assertions in the debug dialog, too.

I don't find any quick ref guides to updating scripts to work with 
2.10... any pointers to docs online re: what to look out for?


-c


gimp: Gimp-Core-CRITICAL: gimp_channel_push_undo: assertion 
'gimp_item_is_attached (GIMP_ITEM (channel))' failed
gimp: Gimp-Core-CRITICAL: gimp_channel_push_undo: assertion 
'gimp_item_is_attached (GIMP_ITEM (channel))' failed
gimp: Gimp-Core-CRITICAL: gimp_channel_push_undo: assertion 
'gimp_item_is_attached (GIMP_ITEM (channel))' failed
gimp: Gimp-Core-CRITICAL: gimp_channel_push_undo: assertion 
'gimp_item_is_attached (GIMP_ITEM (channel))' failed
gimp: Gimp-Core-CRITICAL: gimp_channel_push_undo: assertion 
'gimp_item_is_attached (GIMP_ITEM (channel))' failed
gimp: Gimp-Core-CRITICAL: gimp_channel_push_undo: assertion 
'gimp_item_is_attached (GIMP_ITEM (channel))' failed
gimp: Gimp-Core-CRITICAL: gimp_channel_push_undo: assertion 
'gimp_item_is_attached (GIMP_ITEM (channel))' failed
gimp: Gimp-Core-CRITICAL: gimp_channel_push_undo: assertion 
'gimp_item_is_attached (GIMP_ITEM (channel))' failed

This does not crash, but obviously the script no-longer works.

Welcome to the script-fu console!  And yes, things which worked in
even 2.9.6 no-longer work.  Happy lisping (if such a concept is
possible), or else just "good luck with debugging it".

ĸen


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

[Gimp-user] 'critical error' running luminosity mask script

[Casey Connor]

Hi -- I just filed a bug (here 
) for a 'critical 
error' that happens for me with 2.10 RC1 (AppImage from here 
).


I thought I'd write here in case anyone had any ideas for workarounds 
that I might try until the bug gets fixed. E.g. maybe there is something 
obviously deprecated that the script is doing? (I didn't write the 
script, but I modified it slightly.) It worked fine with 2.9.5. The 
script is attached at the bug report.


Thanks for any ideas!

-Casey


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

Re: [Gimp-user] GIMP 2.10-RC1 Previews Loading Slowly

[Casey Connor]

What I meant by "what are your disks doing" is what kind of activity is 
happening... i.e. open up the performance monitor and watch the disk 
activity. I was wondering if something was bogging down the disks (even 
if you don't believe you are doing anything else to any disks, something 
on your computer might be.)


-c


Where did you download the GIMP 2.10 that you are testing?
The menus are loading slowly? Meaning, you click on "Colors" at the
top
of the screen, and the opening of the menu is not instant? Or did you
mean that the dialog windows appear slowly once you have selected an
option from the menu?
Not sure, but it sounds slow to me... I frequently edit ~90MB 16bit
tiffs and the previews when adjusting color are around 1 second
(desktop
i7 4770K, 16GB RAM), so I'd expect yours to take on the order of 2-3
seconds. If you want to upload a test image somewhere I'd be happy to
poke at it.
What are you disks doing during this period?
I have had issues with color management slowing things down, but
you've
already tried that. Have you tried disabling "Interface -> Enable
layer
& channel previews"? I'd be surprised if it fixed your issue, but when
I've had complicated layering stuff going on, my memory is that it has
helped. Wish I had other ideas for you...

-c

I downloaded and installed 2.10 on my internal SSD.
What I mean is that when I click to open a box such as color balance it takes a
noticeably longer time to load compared to 2.8.
I'm only using my SSD during the editing process.
I tried disabling channel previews and it didn't help the speed unfortunately
Thanks for your time though!



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

Re: [Gimp-user] 'critical error' running luminosity mask script

[Casey Connor]

You said you had edited the script - did you not use the script-fu
console and its included help for that ?  It's some months since I
last had to do that, I'm rusty on the details.


Yeah it was a couple years ago, so it's lost to the fog of memory. :-) I 
think I was updating an old script to be compatible with the more recent 
versions of gimp. I think I just edited the text file directly. Anyway, 
guess I'll dive back in again.


I reported it as a bug instead of just debugging the script because gimp 
popped up a 'critical error' with the stack trace and requested in the 
dialog that I file a bug about it... didn't seem like it was just a 
script error, in other words. Sound appropriate?


Thanks,
-c

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

Re: [Gimp-user] 'critical error' running luminosity mask script

[Casey Connor]

I'm not the qualified person to respond to this, but: my understanding 
was that App-Image versions use that directory so as not to mess with 
normal installs, which is exactly how I would hope it would work... e.g. 
they're supposed to be 'portable' etc. but need to store their user 
settings somewhere, so... seems reasonable? The CCE uses yet a different 
directory: GIMP-CCE-AppImage...


Or did you mean something else?


You might have that directory, but in my from-source RC2 install my
local scripts are read from

~/.config/GIMP/2.10/scripts/

i.e. GIMP not GIMP-AppImage : something different in how your
version was built ?  I only ask because there will be enough pain
from updating old documentation without multiple variants of the
directory name.

ĸen


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

Re: [Gimp-user] 'critical error' running luminosity mask script

[Casey Connor]

Thanks a bunch, Rich -- that script works without error and much faster, 
too, and the masks are in the proper order when done.


But it seems a lot less aggressive; meaning, the "LLL" mask still 
includes much of the image, not just the brightest parts. It's working, 
just doesn't generate as strong a separation as I would need to make it 
useful.


If I have time to poke around at it, I will. And if there are any other 
luminosity mask scripts out there I haven't heard of, I'm all ears! (In 
my secret dreams I hope that a scripter somewhere will make a fancy 
exposure-blending mask-making tool...)


Much obliged,

-c



I do not suppose any of you mailing list guys ever even think of looking at the
gimpusers forum, after all why should you.

but similar question came up a few days ago

http://www.gimpusers.com/mailmsg.php?89758%40forums.gimpusers.com

The Gimp 2.10 appimage is not the best when it come to adding scripts and
plugins, however for once it works.

Just pop the script sg-luminosity-masks29.scm in
~/.config/GIMP-AppImage/2.10/scripts/

looks like this: https://i.imgur.com/5EXnsrb.jpg


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

Re: [Gimp-user] 'critical error' running luminosity mask script

[Casey Connor]

Just to follow up -- Michael Natterer has fixed this... turns out the 
script was working fine but the error dialog was unnecessary. Thanks all!


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

-c

On 04/20/2018 04:14 PM, Pat David wrote:
I’ll have a look at it when I get a moment. Might just need to update 
something simple.
On Fri, Apr 20, 2018 at 5:45 PM Casey Connor 
<gimp-user-l...@caseyconnor.org 
<mailto:gimp-user-l...@caseyconnor.org>> wrote:


> You said you had edited the script - did you not use the script-fu
> console and its included help for that ?  It's some months since I
> last had to do that, I'm rusty on the details.

Yeah it was a couple years ago, so it's lost to the fog of memory.
:-) I
think I was updating an old script to be compatible with the more
recent
versions of gimp. I think I just edited the text file directly.
Anyway,
guess I'll dive back in again.

I reported it as a bug instead of just debugging the script
because gimp
popped up a 'critical error' with the stack trace and requested in
the
dialog that I file a bug about it... didn't seem like it was just a
script error, in other words. Sound appropriate?

Thanks,
-c

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

--
https://patdavid.net
GPG: 66D1 7CA6 8088 4874 946D  18BD 67C7 6219 89E9 57AC


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

Re: [Gimp-user] [offtopic] image viewer which can show the location on a map

[Casey Connor]

Brilliant!

The open source paradigm in action:

A says, I with I could do this thing...
B says, I bet you could use that thing...
C says, You mean like this?


You forgot:

D says, You can already do that with program X
E says, And program Y

:-),
-Casey

P.S. A says, Your script didn't work for me on file Z
:-)

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

Re: [Gimp-user] [offtopic] image viewer which can show the location on a map

[Casey Connor]

Here is a bash script that will take an image file and open a link in 
your browser to the openstreetmap.com site at that location.


It requires that the "exiftool" utility be installed, which you can 
install e.g. on debian-based systems with:


*sudo apt-get install libimage-exiftool-perl*

Put the following in a file (preferably in a location that is in your 
executable path), call it something like "locatepic".


*#!/bin/bash**
**sensible-browser `exiftool -c "%.6f" $1 | grep "GPS Position" | sed -r 
's/^.*: ([0-9]*\.[0-9]*) ([NS]), ([0-9]*\.[0-9]*) 
([EW])/http:\/\/www.openstreetmap.org\/search?query=\1%20\2%2C%20\3%20\4/g'`*


(If your distribution doesn't have "sensible-browser" or you don't like 
which browser is used by it, you can use "xdg-open" in its place.)


Run this command one time:

*chmod ug+x locatepic*

...to make the file executable. Then run it with:

locatepic /path/to/your/picture.jpg

(Or if the executable is not in your path, use /path/to/locatepic 
/path/to/your/picture.jpg)


There are various ways to integrate this into your desktop environment 
(e.g. so you can right-click on an image and choose "locatepic"), but I 
will leave that as an exercise to the reader. Some useful links:


https://developer.gnome.org/integration-guide/stable/desktop-files.html.en
https://specifications.freedesktop.org/desktop-entry-spec/latest/index.html
https://stackoverflow.com/questions/4824590/propagate-all-arguments-in-a-bash-shell-script?utm_medium=organic_source=google_rich_qa_campaign=google_rich_qa

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

Re: [Gimp-user] [offtopic] image viewer which can show the location on a map

[Casey Connor]

Sorry, the ASCII-ification added a bunch of asterisks. Let me try that 
again:


Here is a bash script that will take an image file and open a link in 
your browser to the openstreetmap.com site at that location.


It requires that the "exiftool" utility be installed, which you can 
install e.g. on debian-based systems with:


sudo apt-get install libimage-exiftool-perl

Put the following in a file (preferably in a location that is in your 
executable path), call it something like "locatepic".


#!/bin/bash
sensible-browser `exiftool -c "%.6f" $1 | grep "GPS Position" | sed -r 
's/^.*: ([0-9]*\.[0-9]*) ([NS]), ([0-9]*\.[0-9]*) 
([EW])/http:\/\/www.openstreetmap.org\/search?query=\1%20\2%2C%20\3%20\4/g'`


(If your distribution doesn't have "sensible-browser" or you don't like 
which browser is used by it, you can use "xdg-open" in its place.)


Run this command one time:

chmod ug+x locatepic

...to make the file executable. Then run it with:

locatepic /path/to/your/picture.jpg

(Or if the executable is not in your path, use /path/to/locatepic 
/path/to/your/picture.jpg)


There are various ways to integrate this into your desktop environment 
(e.g. so you can right-click on an image and choose "locatepic"), but I 
will leave that as an exercise to the reader. Some useful links:


https://developer.gnome.org/integration-guide/stable/desktop-files.html.en
https://specifications.freedesktop.org/desktop-entry-spec/latest/index.html
https://stackoverflow.com/questions/4824590/propagate-all-arguments-in-a-bash-shell-script?utm_medium=organic_source=google_rich_qa_campaign=google_rich_qa


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

[Gimp-user] .XCompose bug with GIMP?

[Casey Connor via gimp-user-list]

Hi --

I frequently use the compose key to enter special characters in text 
fields in GIMP, e.g. ♯ (that's a sharp symbol, not sure if it will make 
it through the mailing list.) Works fine.


I recently set up an .XCompose file to get convenient access to a couple 
more specific symbols (U+1D106 and U+1D107):




include %L
   : "턆" # measure repeat symbol start
   : "턇" # measure repeat symbol end



It works fine, but not in GIMP.

If I open LibreOffice Writer, I can enter the character as expected. If 
I open GIMP, no character is entered in to the text field.


If I copy the character from LibreOffice to GIMP, it inserts properly in 
to the text field. The font choice doesn't seem to be the issue in GIMP, 
as the selected fonts do seem to have the character in them.


Is this a GIMP bug? Did I read somewhere that .XCompose is interpreted 
per application? If so, is GIMP ignoring it?


Thanks for any insight.

-c


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

Re: [Gimp-user] .XCompose bug with GIMP?

[Casey Connor via gimp-user-list]

Just as a follow-up -- I am using a GIMP AppImage 
<https://github.com/aferrero2707/gimp-appimage/releases/tag/continuous> 
and I notice (thanks to the help of some folks online) that the Input 
Method list for the text layer in GIMP only has two entries: System 
(Simple) and None. Others are having success with the "X Input Method" 
but I don't have it listed. Is this the cause of my issue? Is there a 
reason the AppImage would lack that?


On 1/13/20 12:43 PM, Casey Connor via gimp-user-list wrote:

Hi --

I frequently use the compose key to enter special characters in text 
fields in GIMP, e.g. ♯ (that's a sharp symbol, not sure if it will 
make it through the mailing list.) Works fine.


I recently set up an .XCompose file to get convenient access to a 
couple more specific symbols (U+1D106 and U+1D107):




include %L
   : "턆" # measure repeat symbol 
start
   : "턇" # measure repeat symbol 
end




It works fine, but not in GIMP.

If I open LibreOffice Writer, I can enter the character as expected. 
If I open GIMP, no character is entered in to the text field.


If I copy the character from LibreOffice to GIMP, it inserts properly 
in to the text field. The font choice doesn't seem to be the issue in 
GIMP, as the selected fonts do seem to have the character in them.


Is this a GIMP bug? Did I read somewhere that .XCompose is interpreted 
per application? If so, is GIMP ignoring it?


Thanks for any insight.

-c


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

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