Re: [Gimp-user] Change background colour with GIMP 2.10.22

[Jay Smith]

Zoltán,

I am eager to know what other users have to say, whether on the list or 
directly to you, Zoltán.


I have a similar application (stamps for collectors).  I have 
experimented with various "green screen" techniques for years, and using 
other programs as well, but I have never been able to find anything that 
can fully do what I need to do.  The problem for me is that sometimes 
the printed design of the stamp (which can be various colors), or the 
cancellation/postmark on the stamp goes to/over the edge of the stamp 
paper.  Thus at that point (near the edge) there are problems with 
selections "eating into" the stamp area, etc., such as the selection 
following the area of the postmark into the stamp.  We have also not 
been able to completely eliminate all vestiges of background color right 
up to the edge of the stamp's paper (keep in mind that on old stamps, 
not all edges are absolutely clear cut as they are on a modern stamp) -- 
this may be similar to Zoltán's problems at the edges of coins if the 
edge of the coin is not perfectly smooth.


Since we never found a satisfactory solution in "old" GIMP we did not 
attempt to automate it back then (as Zoltán did), thus we don't have the 
problem of the automation no longer working well or quickly.


However, our original problem remains as much as ever.  We can get "sort 
of close", but that's just not good enough.  And we need something we 
can use for making tens of thousands of stamp images.


I will watch this thread with interest.

Zoltán, I welcome learning any advice you can give as you solve your 
problem.


Jay Smith


On 03/23/2021 07:15 PM, Zoltán Kluik via gimp-user-list wrote:

Dear GIMP users,

I would like to ask your help regarding removing background and change it
to white.
I'm dealing with coin pictures mainly medieval silver coins. I take the
photo about coins with green / dark green background. In the past on Ubuntu
I used the GIMP 2.8.16 version where I applied the foreground selection
tool. Here I just simple rounded the coin, press enter and the program
after some seconds selected my coin. I loved this method, because it takes
only seconds to select the coin.

Last year I have upgraded GIMP to version 2.10.22, but from this time I
have a big problem with time consumption and also with the quality of the
changing the background. Now in 2.10.22 I open a picture, using foreground
selection tool, but in this version there is a motor feature where I can
select Global- and Levin matting. I use both with iteration value 1. First
Global is selected, coin is rounded, pressing enter, selecting the
foreground with the mouse, again pressing enter. Here the problem is that
under the coin where the green background’s colour was a little bit darker
there are green dots. So after Global,  I apply the Levin matting. With
this the dots are deleted, good, but where it is not selected the coin,
there the surface (mainly at the edge) is not the original, blurred or not
as the original was. Here I can use the adding to background selection or
adding to the background within extra zoom possibility to make sharper the
edges. Finally after 10 minutes however it is the same result as in 2.8.16
was 30 seconds and automatically.

So what did I wrong or how I should do to make this process easier and
faster as it was in the earlier version?

Thank You in advance for Your advice!

Zoltan

Zoltán Kluik  ezt írta (időpont: 2021. márc. 23.,
K 14:10):


Dear GIMP users,

I would like to ask your help regarding removing background and change it
to white.
I'm dealing with coin pictures mainly medieval silver coins. I take the
photo about coins with green / dark green background. In the past on Ubuntu
I used the GIMP 2.8.16 version where I applied the foreground selection
tool. Here I just simple rounded the coin, press enter and the program
after some seconds selected my coin. I loved this method, because it takes
only seconds to select the coin.

Last year I have upgraded GIMP to version 2.10.22, but from this time I
have a big problem with time consumption and also with the quality of the
changing the background. Now in 2.10.22 I open a picture, using foreground
selection tool, but in this version there is a motor feature where I can
select Global- and Levin matting. I use both with iteration value 1. First
Global is selected, coin is rounded, pressing enter, selecting the
foreground with the mouse, again pressing enter. Here the problem is that
under the coin where the green background’s colour was a little bit darker
there are green dots. So after Global,  I apply the Levin matting. With
this the dots are deleted, good, but where it is not selected the coin,
there the surface (mainly at the edge) is not the original, blurred or not
as the original was. Here I can use the adding to background selection or
adding to the background within extra zoom possibility to make sharper t

Re: [Gimp-user] Resizing

[Jay Smith]

In addition to ImageMagick which can do all sorts of great stuff, to do 
this kind of thing we had to resort to writing a Perl program.


Our inputs are TIFFs and our outputs are JPEGs in four different pixel 
size-ranges.  The output pixel size for some is fixed (i.e. for 
thumbnails) and for others is variable, but within a range, depending 
upon the input size.


On one hand it is "simple" when you describe it in words, along with a 
little hand-waving.  However, trying to do it programatically is a bit 
messy.


Perl does have image handling modules that help a lot.  (Disclaimer, I 
did not personally do any of the real work; I just did the talking and 
hand-waving.)


We have a library of many tens of thousands of source images as TIFFs. 
We keep them as TIFFs for ultra-long-term purposes, also for 
print-on-paper use, and don't want any compression, etc., etc.  New 
source images are dropped into the library at will.  A command is run 
several times per week, or as needed, which compares all the sources to 
all the targets and makes/remakes any new targets where targets do not 
yet exist or any source's timestamp is newer than the target.


It can be done.

Jay

On 02/03/2021 04:10 PM, Rick Strong wrote:

You probably need a script that references each file in a folder and
acts on them individually before closing it and moving on to the next
file in the folder.

I used to do that sort of scripting for Corel Draw and PageMaker but I'm
not in that game any more. It should be straightforward for anyone who
knows what they are doing.

Rick S.

-Original Message- From: Jo Kent via gimp-user-list
Sent: Tuesday, January 26, 2021 6:18 AM
To: gimp-user-list@gnome.org
Subject: [Gimp-user] Resizing

I have worked out how to batch resize which I’d great when all the
images start of roughly the same size but I have a batch of images that
vary from 300kb to 4500kb and I want them all to be approx 200kb is it
possible to set a size rather than a percentage/pixel size that creates
a variety of sizers, smaller but not what I require. To resize each
image individually is very time consuming.
Help!


--
Jay Smith

e-mail: j...@jaysmith.com  mailto:j...@jaysmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
1-800-447-8267
Fax: Int+US+336-376-6750
___
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] Old Gimp 2.6.6 vs 2.10.18: Differences in Scale Image dialog behavior and files coming in from scanning

[Jay Smith]

ze is the same?


I know experienced users of *new* Gimp and the developers are surely 
tired of people like me not understanding changes in the fundamentals 
and questioning if something is wrong or has a bug.  I thank you for 
your patience.  Please be gentle.


Thank you very much.

Jay Smith
___
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] Ticket numbers

[Jay Smith]

On 12/11/2019 11:57 AM, Epick wrote:

Hello guys, I have made tickets for our party, but I'm having
troubles with one thing. I need to print 360 of those tickets and
each should have its number starting from 1 to 360. How can I
efficiently number those tickets? >

Epick


Attachments:
*
https://www.gimpusers.com/system/attachments/1313/original/ticBlank.png




This is not a task suitable for an image editing program.

I would do it another way.

Use a word processing program that has an auto-numbering function to 
develop the framework for the area of the ticket, with the number to 
appear (overlay) on the image you have made in an image editing program.


The easiest way to accomplish that would be to print the tickets in one 
run through the printer and then print ON THEM them AGAIN from word 
processing program to add the number on top of the image.


However, even this would be more work than simply hand-writing (oh no, 
not that) 360 numbers.  You could write the numbers faster than it 
took you to even think about these emails.


Jay Smith
___
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] Scanner/Camera menu item not available

[Jay Smith]

On 04/10/2017 07:15 PM, Kevin Cozens wrote:

On 2017-04-09 03:32 AM, Liam R. E. Quin wrote:

Is there anything for Linux systems that competes with XSane?


Another program for scanning is VueScan. IIRC, the website states they
also support older scanners. I think they are also supposed to handle
scanners that have the ability to scan slides.


Regarding VueScan, I have used the free version, and quickly paid for 
the pro version.  It is worth every single penny.  The owner has quickly 
and very helpfully responded to my technical questions which dealt with 
scanning issues, not product issues.  I am just a user and have no 
relationship with the product or owner.  However, I could not imagine 
using any other product and would have been happy to pay much more for it.


An additional benefit, other than dozens of other useful features, of 
VueScan: If you want to create a calibration for your scanner(s) [using 
a color target you have to obtain elsewhere], you can load that 
calibration from within VueScan.  It really helps deal with the color 
problems caused by some scanners, or just some problems caused by 
scanners as their electronics age.


And yes, it can deal with slide scanners, etc., etc., etc.  Their 
scanner list is in the hundreds of models.


Jay

--
Jay Smith

e-mail: j...@jaysmith.com  mailto:j...@jaysmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
1-800-447-8267
Fax: Int+US+336-376-6750
___
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] Printing

[Jay Smith]

he 
paper.  Try it and you will see.  I just doubled one and it halved the 
resolution automatically.  In any case, your goal is to get to the print 
size you want, with a resolution of approximately 300 dpi/ppi.  Much 
more than 300 is completely wasted on most print devices that normal 
folks own.


Also, though others may disagree with me, I strongly suggest that you 
work in a NON-LOSSY file format, such as .tif (TIFF).  If you work in 
.jpg (JPEG), every time you save the image, data is LOST -- do it 
several times and you will end up with a fuzzy mess.  I do everything in 
.tif (TIFF), including printing.  Yes, TIFF files are huge.  If the file 
size is causing you a problem, you can as a separate and last step, once 
your TIFF file is saved, do a SaveAs (to create a new copy/version) to 
.jpg (JPEG) file format.  That is tremendously smaller file size and 
might print faster for you.


We scan to TIFF, edit as TIFF, save as TIFF.  We then use a different 
set of programs and scripts, some of which we developed, to 
automatically create a whole range of sizes of JPEG files for use on our 
website.  We can always go back to the non-lossy TIFF version to change, 
fix, edit, etc. and then automagically re-create the JPEGs.  We do this 
with tens of thousands of stamp images.


What you want to do is a bit different, you said you want to PRINT, 
which involves different concepts and math than on-screen viewing use.


Also, be aware that different publishing or word processing programs 
into which you might want to import images for printing (i.e. Word, 
PageMaker, FrameMaker, etc.), treat different image file formats 
differently.  Some mess with them and re-interpret them and some don't, 
depending upon the program and the file format.  That is a whole 
different subject.


If you have GIMP related questions, please continue this discussion on 
the list/forum.


If you need more stamp-related (i.e not necessarily Gimp), you are 
welcome to email me directly.


Jay Smith
___
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] can't keep proportions

[Jay Smith]

Mattia,

You said:


also, it's not clear to me why 400 x 200 and 420 x 220 is not keeping
aspect ratio? the vertical increases exactly the same amount of the
horizontal


It sounds to me like the problem is that you are confusing "same amount" 
with "same proportion".  They are _not_ the same thing.


Increasing 200 to 220 is a proportional increase of 10%.

If you increase 400 by 10%, that becomes 440, _not_ 420!

Jay


On 12/19/2016 03:18 PM, Mattia wrote:

thank you for the help, much appreciated.
this will cause the border to look uneven however, isn't there a work around to
this?
also, it's not clear to me why 400 x 200 and 420 x 220 is not keeping aspect
ratio? the vertical increases exactly the same amount of the horizontal


If you add the same number of pixels to both the width and the height
the aspect ratio will change UNLESS the image is square (height =
width) - this is a simple consequence of basic arithmetic.

If you want the aspect ratio to be unaltered you will need to add more
pixels on the shortest sides of the image than you do on the longest
sides - how may more being determined by the aspect ratio of the
original image.

For example if the image was 400 x 200 pixels adding a 10 pixel border
to all sides would give 420 x 220 - which alters the aspect ratio.
Adding 10 pixels each side and 5 pixels top and bottom gives 420 x 210
which preserves the aspect ratio.




--
Jay Smith

e-mail: j...@jaysmith.com  mailto:j...@jaysmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
1-800-447-8267
Fax: Int+US+336-376-6750
___
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] Comments on GIMP

[Jay Smith]

On 08/07/2015 05:28 PM, George Misdary wrote:


I'm not certain if this is the right place for this, but here goes,
A few weeks ago I was on a mission to find a simple, yet effective, image 
editing program for a project I'm working on.After several frustrating 
experiences with a bunch of 'complete duds' and 'nice trys', I finally came 
across the GIMP.
Within a few minutes of using GIMP, my reaction was simply WOW! Over the few weeks since I've been 
using it, that reaction has only continued to flourish and expand.In every step, so far, I've found 
GIMP to be unbelievably intuitive, logical, stable, capable, powerful, and simply brilliant to 
use.It is far and away one of the best programs I've ever used, not only as a graphics program but 
period!For every function that I thought "Hmm, it'd be nice if ...", within a few 
seconds/minutes of poking around on the hyper-intuitive interface; I've not only found exactly what 
I was looking for, but something-like a dozen other ways to expand upon what I was looking for. 
Rarely do I find this level of... maturity in a program and for a program that is released for free 
none-the-less, I'm simply blown away!!I'm not exaggerating when I say that on a practically daily 
basis, that I've used GIMP, I find myself saying "I really love this program".
I'm sure you hear things like this fairly regularly, but I still wanted to send 
this email to give a HUGE shout-out to the developers, contributors, and all 
involved with making this such a kick-a## product!
Kudos and THANK YOU!!!
Regards,GM


George,

If I did not know better, I would think you were a friend of one of the 
developers.  :-)


Seriously I do have a question:  What other image editing program(s) do 
you have experience with?  (Not just "tried them", but actual 
significant use.)


My reason for asking is that Gimp is sometimes more intuitive for people 
who don't have a lot of experience with another image program (because 
they are somewhat expecting things to be like that other program).


You are a bit special -- in my experience, most people have a more 
difficult learning curve than you seem to have had.


Jay
___
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] What causes random (in error) image color-inverting of TIFFs, over time? Is it correctable?

[Jay Smith]

On 05/31/2015 07:09 PM, Liam R. E. Quin wrote:

On Sun, 2015-05-31 at 17:25 -0400, Jay Smith wrote:


My primary question is whether there is a "particular bit that is

getting flipped" that could be "unflipped" by some sort of non-visual
editing of the source TIFF file?


My secondary question is whether or not other people have seen this

type of problem crop up in large image libraries and what the causes
have been?

The nearest I have seen to this that i can remember involves software
changes - e.g. a different version of libtiff or whatever. For
example, recently some images on  http://www.fromoldbooks.org/appeared
to break, and it turned out to be a version of the jpeg library that
had stopped supporting arithmetic encoding (for software patent
reasons).

TIFF is one of the more complex graphics formats in widespread use;
for my own part I prefer to use PNG because at least the core image
part is relatively simple and well-specified and widely supported.

If by any chance you have both an "uncorrupted" and a "corrupted" TIFF
file, and you know for sure what programs were used to create them and
on what platform (e.g. Linux on SPARC, Linux on Intel-64, 32-bit
Windows on Intel, etc) I'm willing to take a look, althogh I don't
think I have TIFF debugging stuff around any more.

It seems unlikely that the same single-bit error would happen on
multiple images because of a hard drive problem, especially if a RAID 3
or higher storage system didn't detect it. Not impossible - an
infinite number of monkeys typing for all eternity might all type
nothing except page 54 of the January 1936 Great Western Railway
timetable through Crewe - but I'd look for more likely causes first,
the most likely of which might be a software change.

Liam


Liam,

Thanks for your thoughts.

I am not understanding how a different version of "libtiff or whatever" 
could result in the corruption of a very few random TIFF image files 
(each just one of tens of thousands), every now and then, that are just 
sitting there, not actively being used by any process (that I am aware of).


If the corruption happened to many files that were being processed in 
the same manner, from time to time, then I would understand.


As for my idea about a memory or controller error on the server causing 
corruption, I certainly agree with you that it does not seem likely that 
the corruption would be of exactly the same type on the files that are 
affected, and that I have _not_ detected corruption of any other types 
of files or programs.


So, that leaves back to not having any explanation at all.  :-)

Thanks again,

Jay
___
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] What causes random (in error) image color-inverting of TIFFs, over time? Is it correctable?

[Jay Smith]

On Sun, May 31, 2015 at 4:25 PM, Jay Smith mailto:j...@jaysmith.com>> wrote:

Greetings fellow Gimp Users,

I make images using Gimp, but I assume that this question is not
really Gimp specific.

I have tens of thousands of images (postage stamps) on my site.
Every now and then when I am looking at a page I discover that the
image (a JPEG) has had is colors "sort of inverted".  The JPEGs were
created in large batches by a script from UNcompressed TIFF images.
When I go back and look at the the original TIFF, I discover that
its colors are "sort of inverted" -- thus the JPEG is a correct
rendition of the appearance of its TIFF source.

Thus the problem is in the TIFF.  But, the problem happens now and
then, over the course of years.  The TIFFs are _not_ being
intentionally manipulated in that time.  The images was originally
okay, now its not.  It seems to be completely random, just one image
here and there.

Somehow the TIFF is getting corrupted.  I am assuming by a memory
error or a disk/RAID controller error, or such.  The images are
still openable in Gimp.

This is only happening to one out perhaps one out of five thousand
images, every five years.  (I am just *guessing* at the error rate
because I only find out about them by randomly coming across them.)
But, if I have 40,000 images, that is eight images destroyed every
five years.  (And often I am not able to replace the image because I
no longer have the item.)

This example image was originally created in 2006.  I suspect
(mostly guessing) that it was corrupted sometime since 2010.  There
is no reason that it would have been edited since that time and file
modification information shows nothing since 2006.

On Ubuntu Linux, using "identify -verbose filename.tif" I can read
the header information.  The only odd thing (to my eye) is that the
create date is 2011 and the modification date is 2006:

Properties:
 date:create: 2011-09-13T11:30:24-04:00
 date:modify: 2006-12-21T00:53:03-05:00

I am guessing that means the corruption may have happened in 2011,
even though the filesystems own file datestamp is 2006 and the
lsattr command shows nothing unusual.


Here is example of a) the resulting JPEG (just to illustrate the
nature of the corruption); b) a similar JPEG to show generally what
it is supposed to look like; c) the corrupted TIFF.

Corrupted:

http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-b_136468_r_l.jpg

Correct image of a similar, but different item:

http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-a_136467_r_l.jpg

This is the TIFF file (corrupted, but viewable in Gimp; colors are
sort-of-inverted)  Size 496 KB:
http://jsa.viewimage.net/temp/gimp/re02-pair_used-vf-b_136468.tif

My primary question is whether there is a "particular bit that is
getting flipped" that could be "unflipped" by some sort of
non-visual editing of the source TIFF file?

My secondary question is whether or not other people have seen this
type of problem crop up in large image libraries and what the causes
have been?

Any thoughts appreciated.

Jay



On 05/31/2015 08:46 PM, Daniel Smith wrote:
> when you say youre seeing thison a web page,
> can i ask what type of system yure serving the pages with?
> wordpress etc? or is it an image generation with php or something?
> thanks
> dan


Hi Dan,

When I say I saw it on a web page, all I meant is that was where I was 
looking when I noticed the corrupted file (JPEG version thereof).


All viewing (of both the JPEG and the original TIFF that the JPEG was 
made from) after that time has been done using Gimp to view the 
corrupted files.


The fact that I first noticed the corrupted JPEG on a web page was not 
relevant and I should not have included that detail.  I only mentioned 
it that way because that is the only way I actually would notice that 
one of tens of thousands of files had been corrupted.  I don't 
systematically go through and view the library of files just for fun.


I am sorry for the misleading detail.

Jay
___
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] What causes random (in error) image color-inverting of TIFFs, over time? Is it correctable?

[Jay Smith]

Greetings fellow Gimp Users,

I make images using Gimp, but I assume that this question is not really 
Gimp specific.


I have tens of thousands of images (postage stamps) on my site.  Every 
now and then when I am looking at a page I discover that the image (a 
JPEG) has had is colors "sort of inverted".  The JPEGs were created in 
large batches by a script from UNcompressed TIFF images.  When I go back 
and look at the the original TIFF, I discover that its colors are "sort 
of inverted" -- thus the JPEG is a correct rendition of the appearance 
of its TIFF source.


Thus the problem is in the TIFF.  But, the problem happens now and then, 
over the course of years.  The TIFFs are _not_ being intentionally 
manipulated in that time.  The images was originally okay, now its not. 
 It seems to be completely random, just one image here and there.


Somehow the TIFF is getting corrupted.  I am assuming by a memory error 
or a disk/RAID controller error, or such.  The images are still openable 
in Gimp.


This is only happening to one out perhaps one out of five thousand 
images, every five years.  (I am just *guessing* at the error rate 
because I only find out about them by randomly coming across them.) 
But, if I have 40,000 images, that is eight images destroyed every five 
years.  (And often I am not able to replace the image because I no 
longer have the item.)


This example image was originally created in 2006.  I suspect (mostly 
guessing) that it was corrupted sometime since 2010.  There is no reason 
that it would have been edited since that time and file modification 
information shows nothing since 2006.


On Ubuntu Linux, using "identify -verbose filename.tif" I can read the 
header information.  The only odd thing (to my eye) is that the create 
date is 2011 and the modification date is 2006:


Properties:
date:create: 2011-09-13T11:30:24-04:00
date:modify: 2006-12-21T00:53:03-05:00

I am guessing that means the corruption may have happened in 2011, even 
though the filesystems own file datestamp is 2006 and the lsattr command 
shows nothing unusual.



Here is example of a) the resulting JPEG (just to illustrate the nature 
of the corruption); b) a similar JPEG to show generally what it is 
supposed to look like; c) the corrupted TIFF.


Corrupted:
http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-b_136468_r_l.jpg

Correct image of a similar, but different item:
http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-a_136467_r_l.jpg

This is the TIFF file (corrupted, but viewable in Gimp; colors are 
sort-of-inverted)  Size 496 KB:

http://jsa.viewimage.net/temp/gimp/re02-pair_used-vf-b_136468.tif

My primary question is whether there is a "particular bit that is 
getting flipped" that could be "unflipped" by some sort of non-visual 
editing of the source TIFF file?


My secondary question is whether or not other people have seen this type 
of problem crop up in large image libraries and what the causes have been?


Any thoughts appreciated.

Jay
___
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 transformation batch processing

[Jay Smith]

On 05/10/2015 11:45 PM, lloyd_borrett wrote:

G'day,

I have many directories of images, totaling more than 5000 images in total.
Each image might be in a jpg, gif or png file format.
I want to change all images to have a 1:1 aspect ratio, on a white background.
I want no image to exceed 1000 x 1000 pixels at 72 dpi.
Images already within the 1000x1000 limit should be extended to have a 1:1
aspect ratio, as required.
At no point is any image scaled upwards in size.
All images should be saved in a suitably compressed way for displaying on web
sites.
The new images should be written into a sub-directory, with the original images
being left in place and unchanged.
Would like to do this as a single batch process, if needs be per directory.

Here are some examples as to what should happen:

1200x1200: Image re-sized to 1000x1000. Save compressed.

1600x1200: Image re-sized to 1000x750. Then extended to 1000x1000, centred on a
white background. Save compressed.

1200x1600: Image re-sized to 750x1000. Then extended to 1000x1000, centred on a
white background. Save compressed.

750x750: Save compressed.

800x600: Image extended to 800x800, centred on a white background. Save
compressed.

600x800: Image extended to 800x800, centred on a white background. Save
compressed.

Is it possible to achieve the above using Gimp?

If so, how?

If not, can you please recommend a image processing tool that can do this?

Best regards, Lloyd Borrett.



Though we have not done some of the specific tasks or had some of the 
specific limitations/operations you describe, we have done operations 
fairly similar to this that require a lot of complex if-then-else logic. 
 To accomplish this, we used Perl and Imagemagick -- this was a few 
years ago, but I think there is/was a Perl image processing module to 
aid in such situations.


I don't recall all the details and I can't help with code samples. 
However, the good news is that the input was in the tens of thousands of 
images and the output was 4x the input (there were four output streams, 
not just one as you need, because our output had in four size ranges, 
not just your one range).  While the code took a bit of work to develop, 
the actual running (and re-running because there were always new or 
modified inputs that had to be detected/compared as new and thus new 
output created), was surprisingly fast.  Obviously the bigger the 
machine (I think we were running on a machine 16 cores and 16 GB of 
RAM), the faster the results.


One or two tiny suggestions.  You describe that the output needs to be 
centered on a white background (if the output is less than 1000 in a 
particular dimension).  The "white background" should be a command line 
parameter type of setting so that you don't have to dig into the code to 
change background color that for a particular run.  You may also want to 
consider the potential use of transparent background (if supported by 
file type of the image type being used for the output) and do the "color 
of background" on the display side (if possible) rather than in the 
image -- that would give you greater flexibility; then you might just 
need a one-line CSS change for your entire website rather than 
regenerating umpteen images.


Jay
___
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] How to swap image colors

[Jay Smith]

On 10/23/2014 02:57 PM, CoolB wrote:

The font used is 'Palatino Linotype Bold'.

Chris

http://www.myfonts.com/WhatTheFont/results?ch%5B0%5D=S&ch%5B1%5D=y&ch%5B2%5D=s&ch%5B3%5D=t&ch%5B4%5D=e&ch%5B5%5D=m&wtfserver=wtf_b_41&id=000a3b05541d8b6d000d09763046&glyphcount=6&imageid=0&x=66&y=37


Thanks for finding out what font it is. I used the steps mentioned and that
worked for the words, but there is a logo to the left that it didn't work for.
Also now the word looks crappy, due to an outline.


Attachments:
* http://www.gimpusers.com/system/attachments/162/original/Image2.png


In your sample image, I don't see a "logo to the left".  Do you see it 
when you look at your PNG ?


I don't know why there is an outline in the word.  That's not right at 
all unless that's what the font you used looks like (with an outline in it).


When you create the word, be sure your background is the color you want 
(I forget whether you want colored letters on white background or the 
opposite).  And be sure you using the opposite color when creating the 
word.  There is no "messing around" beyond that -- in regard to the 
word.  It should be created at the size you want and then not messed 
with (which means that to create other sizes, you should retain access 
to your original source of the font).  For best quality text, don't 
later enlarge or shrink, re-create at the needed size (this is where a 
properly constructed scalable font in a vector-based program is most 
helpful).


Jay



___
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] How to swap image colors

[Jay Smith]

On 10/23/2014 01:51 PM, CoolB wrote:

It depends on whether the words are dithered or not.  If there are
sharp edges
and the image really only has two colors, try the following:

Click on the eyedropper (or O (O not 0), then click on the words to
make the
color of the words the foreground color.

Click on the color tool (or O), then click on the words to
select all
of the color in the words.  Don't use the magic wand, as it only
selects colors
which are contiguous.

Invert the selection (Select/Invert or I).

Click on the Bucket Fill tool (or B).
Look in the tool options to make sure the fill type is "FG color
fill".

Click on the background area to turn it the color of the letters.
The whole image should now be the same color.

Invert the selection again.

Click in the tool options to change the fill type to "BG color fill".
Click on the words to turn them the background color.

If the words are dithered it's more difficult as you need to change
all the
"in-between" colors to an appropriate "in-between" color.

If you need that let us know and we can go into more detail for that.


Thanks for your reply. I'm not really sure how to tell whether the words are
really dithered or not. There are no sharp edges around them or the logo though
that I'm trying to swap the colors on.

Attached is what I'm working on.

Attachments:
* http://www.gimpusers.com/system/attachments/161/original/Image.png



Yes, the letters/logo are dithered.  The edges are "fuzzy".

Since this is a very simple text-logo, if you know and can get access to 
the font used for the original, you could much more easily (and in 
higher quality and more quickly) recreate by using text in an image 
program of some sort -- actually probably better in a vector-based 
program (Inkscape, Illustrator, etc.) instead of a bit-map-based program 
(Gimp, Photoshop, etc.).


Jay
___
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] logo

[Jay Smith]

On 07/29/2014 12:23 PM, Jim Welch wrote:



Have you ever seen a professional photographer take their logo and "ghost" it, 
then place it on one of their photos so no one will steal their photos off the net?

I have a logo in various formats, including png,  and want to place our logo on 
some of my pictures which are in a jpeg format..  I am not sure of the 
percentage, but I am guessing maybe 10% of the total.  Is this possible with 
GIMP.

Thanks,

Jim


Jim,

This is quite easy to do in Gimp using manual methods, but if you have 
more than a few to do, then I use Imagemagick 
http://www.imagemagick.org/ and create a script that does this.


Using the Imagemagick methods and other scripting techniques (perhaps 
Perl with the Imagemagick Perl module) one can, for example, vary the 
size of the watermark based on the size of the underlying image.


I used to use these Imagemagick/scripting techniques to create JPEGs (in 
four different sizes of each, with the four resulting sizes constrained 
by the original size based on some very complex logic) and add watermark 
to _tens of thousands_ of original TIFF files (leaving the TIFF files 
unchanged, unwatermarked so that they are available to me for other uses).


It is very powerful stuff, but it can take a bit of work to learn.

Jay Smith
___
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] Framing Pictures

[Jay Smith]

On 11/15/2013 06:06 PM, Reinhardt Christiansen wrote:

I would like to add "frames" to some of the graphics I'm using on a
website. The frame I want is really just a white border of 8 or 10
pixels on each of the four sides; the pictures will all be rectangles.

I tried doing a frame like this in Gimp 2.8 (in Windows 8) earlier today
and couldn't think of a way to do this very easily. I thought about
drawing a white line along the edge of each side of the rectangle but
didn't know a good way to draw a straight line of the desired thickness
exactly where I want it. I thought about using the eraser to turn the
edges white but that seemed clumsy.

I'm guessing there is a much simpler way so I hope someone can tell me
what it is. :)


Hi Reinhardt,

I have a need for a similar type of thing, so I have a little experience 
with it.


HOWEVER, first of all, if the purpose of this is for using the pictures 
on a website, you should probably consider if you want to do this task 
with HTML and/or CSS and NOT modify the pictures (if _you_ control the 
HTML/CSS being used on the page).  The framing is really nothing to do 
with the pictures, it is a matter of who you want them presented on a 
particular web page.  What happens if you want to use the same picture 
in some other manner, in some other place, with some other type of frame 
or no frame at all.


However, if you still want to alter the image...

First of all, if it were me, I would COPY all the images to a new folder 
and do this work on the copies.  I would not muck up the original images 
with something like a "frame".


Secondly, if your images are in a "lossy" format such as JPEG/JPG, I 
would seriously consider in that "copying" process, actually saving-as 
(exporting) the original files to a non-lossy format (such as TIFF/TIF 
-- maybe somebody will recommend a less bulky format).  Then do all your 
frame-adding, editing in that COPY that is in the NON-lossy format. 
Then, after all editing is done, save-as (export) from the non-lossy 
format to the JPEG/JPG or GIF or PNG or whatever format you are using on 
the website.  If in the future you have to do any more editing on those 
images, edit the NON-lossy version and re-save-as (export) to the lossy 
format.  (PNG is non-lossy and could be used throughout, but it may not 
be a suitable format for your type of images).


Following those kinds of procedures will insure that you don't 
unintentionally degrade the quality and it will give you back-up 
original files that you may someday be very thankful that you have.


Given all that, what I would do -- and it may not be the best way -- is to:

1) Set the background color to white (or whatever).  In the tool box, 
there is a foreground/background selector.  There is a force-to 
white/black button, a flip white/black back-and-forth button, and 
clicking on the main area will put you into a dialog where you can 
select any color you want.


2) Expand the canvas to a larger size.  Image, Canvas Size...
In that dialog, you want to a) change the size by the total number of 
pixels needed; b) click the "Center" button to auto-center the image on 
the canvas; c) In the resize layers drop-down select ALL LAYERS (even if 
you don't have multiple layers this is probably a good idea based on the 
problems I have run into).  Doing this should give you a white fill on 
the new area surrounding the centered image.


Lastly, it sound like you are somewhat new to Gimp and thus I feel you 
pain.  I have been there.  The way you asked the question suggests that 
you may not yet have a good enough grounding of Gimp basics (such as 
images are areas within a canvas -- the image and the canvas are two 
different things).  You would probably greatly increase your enjoyment 
of Gimp and your productivity using Gimp if you Googled on Gimp overview 
or Gimp tutorial or something to just spend 10 minutes going through the 
Gimp ways of doing things.  I came to Gimp from Photoshop and I had to 
learn/re-learn lots of these concepts myself.


Best of luck.

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

Re: [Gimp-user] Question about bump map location

[Jay Smith]

On 09/02/2013 03:32 PM, Judy Wilson wrote:

snipped

My question: I would like to put a "watermark" of my logo on images, and
I can do so with the Map, Bump Map Filter. However, the location of the
bump map is a problem. At 0 on the X and Y Offset sliders, it goes into
the upper left hand corner. OK. The problem is the sliders only move to
-1000, and my images are often larger than that, and I want to put the
bump map into the lower right hand corner, and the sliders will not
allow that. Typing in the numbers doesn't work, and moving the bump map
in the preview with the middle mouse button doesn't work. Of course if I
make the images smaller I can get it into the right hand lower corner,
but I want to use the larger image. Any solution for this, or do I have
to just live with this ... defect(?) for now. Thank you!

Judy Wilson


Judy,

Thanks for all your efforts to support The Movement.  :-)

I can't answer the question you are asking, however, I use a perl script 
that invokes ImageMagick to add watermarks to large quantities of images.


http://www.imagemagick.org

Since I do put my watermark in the upper left corner, I have not paid 
attention to whether ImageMagick can apply the watermark based on the 
position from the lower right corner, but I would guess that it can.


And if the answer to that is no, there is another trick you could try, 
especially if you are using a script to batch process.  First, make your 
watermark image upside down and backwards.  Then rotate each image 180 
degrees, apply the watermark, flatten the image, and rotate it back to 
upright.


Last note: When I batch process to apply watermarks, I always only apply 
to _copies_ of the images as invariably I later need the original 
without watermark for some other use.  (This also prevents destroying 
the original if your batch script does not do as expected.)


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

Re: [Gimp-user] suggestion for Gimp

[Jay Smith]

On 08/08/2013 03:47 PM, maderios wrote:

Hi
This positive proposal could end the eternal discussion "save vs.
export", etc 
Developers could offer two versions of Gimp:
- One version for amateurs with the gimp 2.8 behavior
- One version for professionals with the gimp 2.6 behavior that allows
to save files quickly and normally just like most free or commercial
editors images.
This would allow everyone to be satisfied
Greetings



I'm just a user, and do not speak for anybody other than myself, but...

Your approach would mean maintaining *two* different programs which 
would continue to diverge over time.  I very much doubt that "the 
developers" have the energy to do that -- sometimes it seems that they 
don't have enough energy to do all that they would like with just one 
version.


It seems to me that "the developer's" point of view is that amateurs 
should use a simpler program and not use Gimp at all.


This is open-source software.  You are welcome to become a developer, 
fork the project, and do all this yourself or you can build a team to do 
it.  Or you can hire people to do it for you.  But asking the developers 
-- all volunteers -- to increase their workload (the divergence would 
keep widening over time) is not how things work in open-source software 
as I understand it.


If my vote counted (which it does not because I am not in the "target 
user group"), I would vote against this export requirement also. 
However, I know better than to waste more energy on the subject.


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

Re: [Gimp-user] Is there a single bit that can accidentally flip an image to negative? (not Gimp specific)

[Jay Smith]

On 07/28/2013 07:00 AM, Elle Stone wrote:

I'm going to call the image that isn't inverted "right.jpg" and the
image that is inverted (not really inverted, but certainly it's not
right) "wrong.jpg", to avoid typing really long file names.

"Right.jpg" doesn't have an embedded ICC profile. Right.jpg was
created using Gimp, according to the metadata. Upon selecting it to
open it, Gimp displays a normal-looking thumbnail that resembles
"right.jpg". Upon opening it, Gimp automatically assigns the Gimp
built-in sRGB profile and right.jpg looks like you'd expect.

"Wrong.jpg" does have an embedded ICC profile with description "sRGB
IEC61966-2.1". From the embedded profile metadata it appears to be
some version or another of the original  sRGB profile created by
Hewlett-Packard and Microsoft back in 1998. That profile or versions
thereof has been used by almost all imaging software and operating
systems, until V4 profiles started creeping in.

Upon selecting wrong.jpg with Gimp to open it, the thumbnail looks
more or less like the thumbnail for right.jpg, but not exactly (the
colors are washed out, the blue looks purple, the green looks brown).
But upon actually opening it, the colors go all wrong. However, assign
the Gimp built-in sRGB profile in place of the embedded profile and
wrong.jpg now looks very similar to the right.jpg, slightly washed
out, purple instead of blue, brown instead of green, but not
"inverted".

According to the metadata, wrong.jpg is a Photoshop thumbnail. Was the
original image created by Photoshop? Was the thumbnail really created
using Photoshop and extracted using some software?

I've attached a spreadsheet with the embedded metadata for right.jpg,
wrong,jpg, and the argyllcms version of the original MS/HP sRGB
profile, lined up so the metadata fields match. There are very small
differences in the metadata, not enough to explain why wrong.jpg looks
wrong until the Gimp built-in sRGB profile is assigned.Attached is
also a copy of "wrong.jpg" with the argyllcms version of sRGB embedded
so you can see the color differences.

I'm going to try to extract the embedded ICC profile in wrong.jpg to
see what the tone curves look like. Ofnuts is right, the problem (or
at least one problem) is the embedded profile. And the two images
aren't the same to begin with.

Elle Stone


On 07/28/2013 07:21 AM, Elle Stone wrote:

It turns out that the embedded profile in "wrong.jpg" does have an
incorrect tone response curve. See the attached screenshot comparing
the incorrect TRC to what it should look like. The embedded profile
compresses the original sRGB 1024-point TRC range from 0 to 65535
down to about half the original range, then drops abrubtly to 0. Very
odd. Never seen that before.

So is there some software in your toolchain of softwares that
handles your images, that is somehow embedding a corrupt version of
the original sRGB ICC profile? Is there a timestamp that might let
you know when the "inverted" images were last handled, which might
let you know what software embedded the corrupt profile?

Elle Stone



Hi Elle & Ofnuts,

Thank you for your replies.  However, I think I have wasted (at least 
some of) your time because my original information was incorrect.  But, 
it has been a terrific learning process for me, so thank you!


a) Yes, the two example images are different; they were not supposed to 
be the same.  The "correct/right" one was just to generally show what 
the colors were generally supposed to look like.  I should have posted 
copies of the exact same file (on my server vs on the hosting site), but 
it turns out that would not have helped (or actually would have shown up 
the real problem), because...


b) I was INCORRECT (damn, my perfect record for the year has been ruined 
-- ha!) about the "wrong/negative" original TIFF being okay and the 
original (on my server) JPEG being okay.  They are NOT okay.  However, 
when I look at them using Linux file management and file viewer programs 
they look okay ... that must be because those programs are only looking 
at the preview and are not parsing the whole image file and/or looking 
at the color profile in the image file.  The preview is okay, but the 
image (actually the color profile in the image file) is mucked up and 
looks "wrong/negative".  It did not occur to me that there there were 
_three_ components involved (preview component, profile component, and 
image itself).  LESSON: Look at the precursor image files in Gimp, not 
in file managers or file viewers.


c) Ofnuts: The "wrong/negative" image on the hosting provider is 
identical to the image on my server, when viewed by the exact same tools 
(and also filesize, etc.).  I understand some "image hosting sites" mess 
with images. However, I am using a web hosting service that just gives 
me space and does not seem to mess with anything (thank goodness). 
Thanks for that idea, however.


Okay... the rest of the story.

The "wrong/negative" image dates from 2004 OR EARLI

[Gimp-user] Is there a single bit that can accidentally flip an image to negative? (not Gimp specific)

[Jay Smith]

Hi,

I am sorry that this query is not Gimp specific, but since I use Gimp to 
create the images and I don't subscribe to any "images" list, I hope it 
will be allowed here.  I won't make a habit of it.


From time to time I notice an image in our library or on our website 
has "become" negative.  This is very unsettling as I have used such 
images on our website for years and then all of a sudden I notice in the 
middle of a web page an image that is in negative.


Yes, it is theoretically possible that I simply never noticed this, but 
I have been finding one every few months now for three or four years.  I 
know everybody says "I did not do it", but these are images which have 
not intentionally been manipulated, processed, or uploaded to the 
hosting service for for years.  The differences in image appearance are 
so dramatic that I just can't believe that they have been like that all 
along and I just did not see them.


Also, the images don't seem to suffer any other type of damage.  They 
just become negative.


In the most recent example case (see links below), only the file 
residing on the hosting service has "become" negative.  The original 
JPEG that I uploaded is still correct!  (However, over the last couple 
years, I have found an occasional "negative-ized" original JPEG on our 
server and also a few "negative-ized" TIFFs on our server.  It seems 
that the alteration to negative can happen anywhere along the line.


Since the source JPEG version residing on my server is still okay, the 
damage happened either during transfer to the hosting service or while 
on the hosting service.



Here is an example (the two are images of slightly different objects, 
but the overall appearance is supposed to be extremely similar -- the 
person who can determine the difference is a keen-eyed philatelist):


CORRECT:
http://jsa.viewimage.net/jsa/web/Lists/Sweden/Seals/FlagDay/flag-day-1936-perf-11_mint_149571_r_l.jpg

NEGATIVE:
http://jsa.viewimage.net/jsa/web/Lists/Sweden/Seals/FlagDay/flag-day-1936-perf-11-5-x-11_mint_128795_r_l.jpg


My process: All on Linux.  After scanning to TIFF, the images are edited 
in Gimp as TIFFs. Then they are processed using a script that runs 
various ImageMagick actions to create various sizes (copies) as JPEGs. 
The source TIFF is preserved unchanged (and the original TIFF for the 
negative example above is CORRECT!).  The JPEGs are then uploaded to a 
hosting service (in this case all the 'original' JPEGs still on my 
server are CORRECT!!).


So... The question is.  is there a bit in an image file that can be 
hit by a "stray neutrino" (or whatever happens) that can cause the image 
file to "become" negative".  If yes for JPEG, is it also possible for TIFF?


Or, it seems more likely to me, would such a change from positive to 
negative require a very large number of changes to the image file?


If the type of occasional damage I am observing in a "small" library of 
about 100,000 image files is happening everywhere, to everybody, to all 
types of computer files, we are in deep do-do in the long term.  As they 
say "Houston, we have a problem."


Thanks,

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

[Gimp-user] Save vs export separate discussion forum needed

[Jay Smith]

Though I don't like the "new and improved" methods, they are what they 
are and they are not going to be changed back to the old way.  It is 
really tiring and frustrating to have to listen to all the same stuff 
over and over -- even though (and because) I agree with some of what is 
said and I prefer the old way myself.


Maybe there could be a separate discussion forum just for that subject.

"I feel you pain" about the new way, and the old way would work better 
for me.  However, we need to move on.


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

Re: [Gimp-user] Post GIMP File Management, Organizing & Viewing/Simpler Alternatives & Options PLEASE READ & HELP!!! How Make .JPG Files More Like Tiles or Icons. Once Moved They Stay Set

[Jay Smith]

On 04/12/2013 01:30 PM, FriendlyBeginner wrote:

Hello Jay,

Jay...You told me to take a few weeks off before my head explodes, but I was
challenged & inspired by your posting and decided to go forward and try to
answer you.


<< snip >>


Friendly,

This has really gotten far afield from a Gimp matter and we should not 
be using Gimp electrons on it.


I will cogitate on your latest message, however, please contact me 
OFF-LIST j...@jaysmith.com  with a direct email address that we can 
continue our conversation.


If you prefer to remain in a discussion group setting of some sort, then 
find an appropriate venue (probably related to information management; 
this has really nothing to do with images at this point) and inform me 
of where to listen in.


To respect the Gimp group, we need to take this elsewhere.

Thanks,

Jay

j...@jaysmith.com
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] Post GIMP File Management, Organizing & Viewing/Simpler Alternatives & Options PLEASE READ & HELP!!! How Make .JPG Files More Like Tiles or Icons. Once Moved They Stay Set

[Jay Smith]

On 04/12/2013 11:33 AM, FriendlyBeginner wrote:

Hello Jay,

With GimpUsers forum, am I supposed to type above or below what I'm responding
to? If I select and start typing below the responders text, does this
automatically create the window at the top of my response in the final view?

Jay...I have thousands of cards, not just "things to do" cards, with a lot of
scribbling & writing on them; sometimes a lot of tiny scribbling, drawing etc
whatever.

So to answer your question yes I think I do need images of the cards themselves
and not just the info on them.

I am a novice and have been at this for WEEKS I read twice what you typed below,
and I'm sure it's makes perfect sense but you sorta lost me. But I do I really
do want to understand, but I am not that tech savvvy or at least not at this
moment.

I just want a definitive solution and soon, it's been weeks trying to figure
this out.

Bottomline...I have something very simple I want to do and need a simple
solution...I've been at this for weeks now.

Please read my recent post to I think Rod or Kevin? It should be above this post
I think.

Thanks Jay,

FriendlyBeginner

P.S.Jay...I just read what you suggested below, and I want to understand
what you were getting at, but right now my head is about ready to explode. Maybe
it's no longer relative based on what I typed above, but if it is still relative
I want to understand it, if it will help meThanks Jay...




If I understand correctly -- that in the long run it is the
information
ON the cards that you want to preserve, not necessarily images of the
cards themselves, then it seems to me that you should be using a
database that can either _contain_ images or at least display images
referenced by filenames in the database, as well as textual/data
content.

In such a database, every card would be referenced by some unique
filename/number; it really does not matter much what that
filename/number is.  The card would be viewable either as an
independent
image by whatever methods, but more importantly, from withing the
database's user interface.

The data records in the database would be structured to _eventually_
replace the cards/images.  Over time, you could type in the data from
the cards (images) into the database (while being able to see both at
the same time on screen).  When the data is fully entered, then you
can
sort and organize it any thousand ways you want and you will always
have
immediate access to the image (if still needed).

Jay


Hi Friendly,

I believe that the custom on such lists is to add new content at the 
bottom.  That way, the whole series of messages can be read from top to 
bottom and be in order.


[I have no idea what you are talking about when you say "create the 
window at the top of my response in the final view?"  I am reading / 
writing these messages as ordinary textual emails, not on some website 
-- I don't what mechanisms others use to read / write them.]


=-=-=

I hate to say this when your head is about to explode, but when you said 
"I have something very simple I want to do and need a simple 
solution". you may not fully comprehend what you are getting into.


I agree, it _seems_ simple.  But, it is not trivial.

Often, in "IT" (information technology -- your cards represent 
information), seemingly the simpler the desired result, the more complex 
the real problem is.


It seems "simple" to decide where and what to eat/do/go for dinner 
tonight.  However, it is a massively complex problem that our brain just 
makes seem simple.


!! You may (or may not) find a solution to what you think your problem 
is, however if you find a "simple" solution, I am willing to bet that 
before you are done implementing it, you will realize ... "gee, if I 
could just do this... and that...".


I have experienced this syndrome over and over and over again with 
first-time technical authors who attempt too-simple approaches to 
organizing their data. They end up restructuring their information 
management several times before ending up where I knew they would have 
to ... years later.


While I certainly don't know anything about _your_ cards, I do 
understand cards.  My stepfather made at least one 3x5 card record for 
every day of his life from about the age of 15 to his 60s when he passed 
away unexpectedly.  That's about 18,000++ cards.  There is only one 
person on earth who can translate the tiny squiggly "writing" [also with 
lots of abbreviations and codes] on those cards, my mother.  If she 
started today, there is little chance that she could complete the 
translation in her remaining lifetime.  However, the cards have 
important scientific value -- he was a environmental scientist (long 
before such a term existed) and daily recorded phenology for a specific 
region.


Maybe I have missed it, but I don't think I completely understand 
_exactly_ what you believe your goals are.  It might be helpful (for 
yourself, if not for us), to state them concisely in writi

Re: [Gimp-user] Post GIMP File Management, Organizing & Viewing/Simpler Alternatives & Options PLEASE READ & HELP!!! How Make .JPG Files More Like Tiles or Icons. Once Moved They Stay Set

[Jay Smith]

On 04/11/2013 03:27 AM, FriendlyBeginner wrote:

Hello Everyone,

Please Help Me! I am perplexed & hungry for ideas. I have thousands of 3x5 inch
index cards, all hand written cards. And I have learned how to use GIMP to scan
4 cards at a time, crop, guillotine the 4 cards to make 4 seperate .JPG files,
and then import to my PC (XP).

The cards will (I guess) be numbered like 001.jpg, 002.jpg like that. BUT this
current batch of cards are basically just "things to do" index cards, so I will
likely have 3 folders labeled by priority 1, 2, 3And inside these folders
are all my .JPG files depending on the priority of each "things to do" card.

And all these thousands of cards will be dragged and dropped or otherwise be
constantly moved and/or deleted by me constantly from folder to folder, keep in
mind each of these .JPG files is labeled/numbered.

So when I move them from one folder to another, there is labeling/numbering
conflicts, and the order and positioning will be lost.

What I was hoping for was some sort of a program/file manager whereby I can
treat the ".JPG Files" more like tiles or desktop icons, once moved they are
just there and do not move unless I move them and they do not get automatically
moved by my PC based on "file name/number", yet still be able to move and/or
delete them from folder to folder without conflict.

I really need some "thinking outside of the box" options/ideas. Any alternative
file & folder experts out there? Any file management/organizing programs out
there? Please Help!

  Thank You,

  "FriendlyBeginner"


If I understand correctly -- that in the long run it is the information 
ON the cards that you want to preserve, not necessarily images of the 
cards themselves, then it seems to me that you should be using a 
database that can either _contain_ images or at least display images 
referenced by filenames in the database, as well as textual/data content.


In such a database, every card would be referenced by some unique 
filename/number; it really does not matter much what that 
filename/number is.  The card would be viewable either as an independent 
image by whatever methods, but more importantly, from withing the 
database's user interface.


The data records in the database would be structured to _eventually_ 
replace the cards/images.  Over time, you could type in the data from 
the cards (images) into the database (while being able to see both at 
the same time on screen).  When the data is fully entered, then you can 
sort and organize it any thousand ways you want and you will always have 
immediate access to the image (if still needed).


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] scanner works with linux

[Jay Smith]

On Thu, Nov 29, 2012 at 7:15 AM, Gracia M. Littauer 
wrote:

anyone recomend any newer good Epson scanner that work with linux?


No, but I am using a couple "Epson Perfection 4490 Photo", probably as 
old as what you have.  They work great on Ubuntu Linux (with some 
tweaking of linux USB stuff due to the older Linux distribution we are 
still using).


In any case, more importantly, we use the scanners through Hamrick's 
VueScan Professional scanning software and love it!


  http://www.hamrick.com/

I have had questions about our scanning workflow, color calibration 
questions, and selection of LARGE (11x17) format scanners.  I have asked 
Ed Hamrick and he has always been quick to answer with very helpful 
information.  For me, that alone is work the modest price of the 
program.  [We ended up with a used/refurb Epson GT-1 large format 
scanner which is incredible (faster and better than the usual smaller 
scanners even though it is a lot older).  Original price probably around 
$5000 back in the day, but I found a used one for $400 -- plus delivery 
by truck.]


Very importantly, Hamrick has a huge supported scanners list
   http://www.hamrick.com/vuescan/vuescan.htm#supported
that tells you (by specific scanner model if you want to check on one) 
if it is "supposed" to work on "linux" (generically, at least).


I would not dream of doing the scanning work we do without VueScan.

I also found it extremely useful for our particular scanning work to 
calibrate the scanners, using a 'target', which I obtained from a source 
in Germany. Targets can be very expensive, but this one was only about 
$30 as I recall -- the best and the best deal I was able to find. 
VueScan does support use of the generated calibration file that is 
created as result of calibration process.  [Now I just need to get 
calibrating equipment for our monitors, but that is a lot more costly.]


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] finding layers after file has been closed (.... so much for the new export/save methods)

[Jay Smith]

On 11/18/2012 04:38 PM, Burnie West wrote:

On 11/18/2012 01:13 PM, jenn golden wrote:

However, this is an excellent illustration that this "controversial"
change in the save/export methods is not a perfect solution either.

On the good side, however, Jenn is happy to have "learned the lesson" --
and is fully up to speed with the difference between save and export.

   -- Burnie


Yes, Jenn seems to be taking it well.  Again, I am sorry that she had to 
go through that frustration.


However, when I originally brought up my point that sometimes people (in 
general) have to "learn a lesson" the hard way in order to really learn, 
I was told, in various ways, with varying language, by several of the 
developer group, that I was a terrible excuse for a person -- if I was 
even a human being at all.


Oh well.  Fortunately, I found that reaction more amusing than anything 
else.  The virulence of that reaction told more about them than anything 
else.


I am just saddened that the most of the type of work my company does 
with Gimp is no longer (maybe it never was?) included in the "target 
user/use" definition.  Because it does not make economic sense for a 
company to train and support users in two different graphics programs, 
there will eventually come a time (since I presume the goals of the 
program developers will continue to evolve away from our typical 
workflow), when we will have to switch to _one_ other program to do our 
graphics work.  That's sad because Gimp has so much to offer.  However, 
as the world changes, we all must move on.  Complaining serves no 
purpose since the people who do the work, and thus "own" the program, 
are completely within their rights to do whatever they want.  There is 
nothing "wrong" with that, however, the consequences are sometimes sad. 
Such is life.


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] finding layers after file has been closed (.... so much for the new export/save methods)

[Jay Smith]

On 11/18/2012 03:57 PM, jenn golden wrote:

I totally understood what you both said - but I didn't know that I had
to save it both ways - I only saved it, or exported it at a .jpg... Does
that mean I can't recover the .xcf?

On Sun, Nov 18, 2012 at 3:54 PM, Daniel Smith mailto:opened...@gmail.com>> wrote:

what he said. that's what i meant when i said before that you would
still have the layers, that you had the .xcf file somewhere.
:)
dan



I don't want to "start anything", but this just points out what I said 
originally: It is not possible to always protect everybody from themselves.


I am very sorry for Jenn's misfortune and I do not mean to be 
disrespectful.


However, this is an excellent illustration that this "controversial" 
change in the save/export methods is not a perfect solution either.


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] time saver?

[Jay Smith]

On 11/15/2012 10:13 PM, Jay Smith wrote:

On 11/15/2012 09:48 PM, rmooney wrote:

I enjoy using GIMP, but I'm looking for some help to cut down on my time
watermarking my photos. Currently I am opening a photo, adding text,
rotating
text, duplicating the text layer, then moving each layer to the top
left and
bottom right corners. Surely there must be a way to make this process
quicker?
Any help will be appreciated.



A few years ago I was using Imagemagick for similar watermarking in an
automated batch process.  However, at that time there were some bugs (at
least on our system) that prevented me from getting exactly what I
wanted in terms of text appearance.  However, it was _supposed_ to work
and seemed to for other people.  I suspect it does now (if not then
also) and would work now on our more modern o/s.

http://www.imagemagick.org/script/index.php

When I was using it, it was part of a larger process I ran: making
multiple scaled JPEGs from single TIFFs, and applying the watermark, all
in the same process (without messing up the TIFFs).

We still use Imagemagick for the sizing/scaling to process thousands of
images.  We use a Perl script wrapper to manage the process of running
through hundreds of source directories/folders containing tens of
thousands of images, processing only those that are newer in the source
than the target, and pushing the results to a matching output
directory/folder structure.  (Thus any changed image will get
reprocessed.)  We use a complicated algorithm in the Perl script to
decided the min / max size for each output, with max limitations on
width and/or height (but maintaining original scale), based on the four
target uses and on the physical size of the input object TIFFs (the
TIFFs are all scanned at 100% of size (said from a printing perspective)
at 300 dpi.  The original source objects range from 1x1 inch to 20x20
inches (flatbed scans).  The output sizes need to be "sane" to fit in a
web page that is "sane" and yet takes advantage of whatever size is
available without making the page too wide.  The logic and math of this
hurts my head; among other things, the differences input and output dpi
really warps the math, while you are scaling differently depending upon
various rules.

Anyway, it works great and runs like cat with a bell tied to its tail.
(I'm a cat person, but that would be fun.)  The more RAM and the more
processors the better and if you can control (increase) the number of
simultaneous processes on your machine, you can make it scream.

If we were to go back to watermarking, of course the watermark needs to
be applied _after_ the sizing/scaling, but before saving the JPEG.

You could also set up a "watched folder" type of system into which you
could drop the source images and have a 'cron' job that checks and
processes the folder however often you want.

Jay


One added note: By maintaining separate source (input) and target 
(output) directory structures you 


- Will never damage your source files.

- If you want to change the watermark on the existing target files for 
any reason, you simply change the script doing the watermarking, use 
'touch' (or similar) to change the dates of either the source or target 
files so that the process [a Perl wrapper script] will think the source 
files are newer, and run it again.  All your target files will be 
recreated with the new & improved watermark.


Suggestion: Never delete your target files as a way to tell the process 
to recreate them.  (Instead, move them aside.)  I say this because every 
year I find one or two source files (out of tens of thousands) that have 
mysteriously been corrupted (though not accessed according to the file 
internals), the favorite corruption is that the image turns negative. 
Stray neutrinos??  Anyway, as long as you have your target files, you 
can at least have something usable even if your source has become bad. 
[And another good reason for progressive, non-destructive backups stored 
off premises.]


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] time saver?

[Jay Smith]

On 11/15/2012 09:48 PM, rmooney wrote:

I enjoy using GIMP, but I'm looking for some help to cut down on my time
watermarking my photos. Currently I am opening a photo, adding text, rotating
text, duplicating the text layer, then moving each layer to the top left and
bottom right corners. Surely there must be a way to make this process quicker?
Any help will be appreciated.



A few years ago I was using Imagemagick for similar watermarking in an 
automated batch process.  However, at that time there were some bugs (at 
least on our system) that prevented me from getting exactly what I 
wanted in terms of text appearance.  However, it was _supposed_ to work 
and seemed to for other people.  I suspect it does now (if not then 
also) and would work now on our more modern o/s.


http://www.imagemagick.org/script/index.php

When I was using it, it was part of a larger process I ran: making 
multiple scaled JPEGs from single TIFFs, and applying the watermark, all 
in the same process (without messing up the TIFFs).


We still use Imagemagick for the sizing/scaling to process thousands of 
images.  We use a Perl script wrapper to manage the process of running 
through hundreds of source directories/folders containing tens of 
thousands of images, processing only those that are newer in the source 
than the target, and pushing the results to a matching output 
directory/folder structure.  (Thus any changed image will get 
reprocessed.)  We use a complicated algorithm in the Perl script to 
decided the min / max size for each output, with max limitations on 
width and/or height (but maintaining original scale), based on the four 
target uses and on the physical size of the input object TIFFs (the 
TIFFs are all scanned at 100% of size (said from a printing perspective) 
at 300 dpi.  The original source objects range from 1x1 inch to 20x20 
inches (flatbed scans).  The output sizes need to be "sane" to fit in a 
web page that is "sane" and yet takes advantage of whatever size is 
available without making the page too wide.  The logic and math of this 
hurts my head; among other things, the differences input and output dpi 
really warps the math, while you are scaling differently depending upon 
various rules.


Anyway, it works great and runs like cat with a bell tied to its tail. 
(I'm a cat person, but that would be fun.)  The more RAM and the more 
processors the better and if you can control (increase) the number of 
simultaneous processes on your machine, you can make it scream.


If we were to go back to watermarking, of course the watermark needs to 
be applied _after_ the sizing/scaling, but before saving the JPEG.


You could also set up a "watched folder" type of system into which you 
could drop the source images and have a 'cron' job that checks and 
processes the folder however often you want.


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] dotted text

[Jay Smith]

On 10/25/2012 10:53 AM, komsinica wrote:

I am using Gimp to create worksheets for kids learning a foreign language.  I 
would like to make my text dotted so kids can trace it to practice writing.  I 
am using a Cyrillic alphabet so a dotted font is not an option for me.  It 
would have to be done by manipulating the text.

Thank you very much.


Hi,

I would suggest completely rethinking your approach to the problem. 
Sometimes the answer is in simplicity.


Consider either printing the text in a _pale_ color, or if you only wish 
to use "black" printing, consider setting the "color" of the text to a 
light "color", but printing it on a black printer -- the result will be 
some shade of gray.


The students could then trace around the outside of the pale color / 
gray text.


Would this work and solve the problem without having to create anything 
special?


Furthermore, this solution does not involve Gimp or any image program. 
You can do this in any word processor program.


Best of luck.  Educating children in different languages is very 
important work -- something that has been mostly forgotten in the USA.


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] HELP! What the EXPORT

[Jay Smith]

On 09/21/2012 01:09 PM, scl wrote:

On 21.09.12 at 6:40 pm TinaBina wrote:

Help! I am trying to save a photo for a deadline and cannot export to
my computer as .jpg file to save to iPhotp.

When I go to export the screen (on Gimp) goes grey. The end. What can
I do to get these important pictures on my computer ASAP? Using Gimp
2.8.2 and newest version on MAC.

I am new to Gimp. I tried it once and hated it (that was over a year
ago) and I am not happy this time either. The editing is fine but the
pictures are useless if I cannot access them.

Thank you so much in advance for any suggestions.


Hi TinaBina,

GIMP on Mac has sometimes the bad habit to open dialog windows in the
background. Maybe one of them is open and needs to be confirmed or
canceled first. If the error occurs again, press F9 to see the Exposé
view or press Cmd+Tab to switch through the open windows. Then confirm
or cancel the hidden dialog window.
If that's not the solution: what's your Macs version and where exactly
did you get GIMP from? Are there any error messages shown on the screen
and if yes what's their exact text?

Kind regards,

Sven


While my comment is not Mac specific, and not necessarily even Gimp 
related...


I have seen similar strangeness -- with similar causes as to
what Sven is saying -- on Ubuntu Linux KDE desktop environment.

In addition to trying the methods Sven has mentioned, I have sometimes 
had to go through and _minimize_ all visible windows, one by one, until 
I find a window or dialog that is open, but not showing up in the task 
bar or by ctrl-tab, etc.


Again, I am not saying there is a Gimp problem on Linux in this regard, 
but I am pointing out that the technique of minimizing windows can 
sometimes expose a window or dialog that you did not know was present.


Best of luck to you.

Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] Definition of "project data" .... vs "image data" vs "workspace data"

[Jay Smith]

On 08/07/2012 07:11 PM, Alexandre Prokoudine wrote:

On Wed, Aug 8, 2012 at 2:29 AM, Jay Smith wrote:


However, to me, the XCF does not _currently_ really save what I consider to
be the _project_ data.

Gimp does not save, to my knowledge (please excuse any errors), the
following (and more, I am sure):

- window positions or sizes
- visible dialogs
- viewing magnification magnification
- active tool
- most recently applied filter
- most recently used settings in dialogs (such as Image Size settings
  such as inch vs mm etc.)
etc., etc.


OK, fair point. I can see how a project could have several related
images and certain workspace preferences preserved (i.e. "restore as I
left it"). Maybe Peter would be interested to have a go at this in the
future.

Of all the items listed above only the latter is kinda being addressed
so far. Right now, in Git master, some of the former GIMP filters that
have been ported to GEGL use the skeleton of the experimental GEGL
tool and thus save recent settings automatically. I use it a lot for
applying the unsharp mask filter (but I only scale down and clean-up
stuff with this version, really -- it's not ready for prime time use).


(Or maybe "project" and "workspace" are completely different things??)


To me, they overlap. At least, a little bit.

Alexandre Prokoudine


Alexandre,

Thank you for your very constructive and helpful reply.

See, I _feel_ heard.  And I am a happy camper.

Clarification:  I made the statement "Gimp does not save".  I should 
have said "Gimp does not save in the _image_ file when saving an 
image".   [The program 'workspace' does remember things like what 
dialogs were open when the program was closed.]


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] HATE the new save vs. export behavior

[Jay Smith]

On 08/07/2012 06:53 PM, Alexandre Prokoudine wrote:

On Wed, Aug 8, 2012 at 2:28 AM, Jay Smith wrote:


As many husbands have taken decades to learn (or else they are no longer
married), sometimes "writing all the reasoning down" won't make the wife
feel better.  Right now, the developers are responding to an emotional
situation by saying something like "but we did what was logical, we even
wrote it down first".  In the recorded history of human relations, I doubt
that response has worked on a regular, consistent basis.


Jay,

Let's not try fooling each other. The only thing the former community
is really going to accept is "Sorry, we screwed up, and you were right
all the time. We are going to revert, sorry again".

The former community will probably also accept "OK, we are going to
make this optional", except no two people so far agreed on how exactly
this should be done, and noone so far seems to have understood how
badly it would affect usability and code maintenance.

People just want the old stuff back at any cost. Not gonna happen.


Users become very attached to the software they use.


You make it sound like there are generations of people who passed the
habit of Ctrl+S for saving to PNG from father to son, whereas personal
digital image editing is barely 30 years old :)


When software evolves in a direction different from that user/workflow, the
user experiences *very personal* feelings of *loss*.

The strong feelings expressed in all these "yet another long threads" are
users expressing their feelings of _loss_.

And it is not just their _feelings_.  Some of them will decide that they
will have to migrate to other software which does include them it its
"target user group".  That migration comes at a very real cost of time,
effort, learning, and perhaps money.


Excuse me, but what is wrong with that picture? Human civilization
always needs time to adapt to new things. It was ever so.

Would you tell Wright brothers that they shouldn't have had come up
with their Flyer, because, ye gods, a hundred years later people still
got to spend some time to learn how to get the bloody thing take off?
:)


If the developers have made a mistake, it was possibly overlooking these
"feelings issues" and not expecting such a strong reaction.  That is not to
say that the developers did not have to do what they did.  However, they
should not have been surprised by the reaction.


We knew it was going to be crying and moaning all over the place. We
had early warnings of that, too. And actually we made few adjustments
to the new model to clarify things, e.g.

http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=f4ce57aa9709e492666c16259e81625a3e4a7796

http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=c3e904fab1b29224b7dd55bb5b4af49f34c3b335

Alexandre Prokoudine


Alexandre,

You made a very specific statement:

   "I don't really understand why we need yet another
long thread to go through all these things yet again."

I attempted to explain my opinion of the situation, specifically in 
regard to what you claimed you did not understand.


In return, I got back a dismissive reply that IMHO completely ignored 
the intent of what I was trying to say.  Your response has seriously 
tested my respect for you -- I tried very hard to show my respect for you.


I was not trying to say that users _should or should not_ do/think/feel 
this or that for whatever reason.


I was giving my opinion of the dynamics behind **WHY** they DO 
think/feel this or that.


Either you read my words too quickly without taking time to understand 
what I was getting at or you completely misunderstood what I was saying. 
 Your response does not jive with the intent of what I was writing.


In fact, you just got out a "bigger hammer" to try and pound the problem 
down.


From this I am starting to get the idea that you don't actually _want_ 
to understand the problem; you just want the problem to go away.  If 
that is the case, and as long as that is the case, the problem will not 
go away.


The users are writing from their feelings.  Until you respond to those 
feelings, you will get nowhere.


In summary, IF nearly every one of the developers responses included 
some version of the following statement, nearly half of your "long 
threads" would vanish and life would be good:



 "We understand _ presents a difficult situation for some
  users and we regret the impact that this has had on you.
  Unfortunately, we had to make difficult choices in the subject
  of ___ and the result is that the program will no longer
  fit the workflow of some users.  We feel that the changes we
  have made will be to the benefit of the majority of the user
  community and we are dedicated to continuing the improvement
  of Gimp for the target user community.  We appreciate your
  loyalty to Gimp an

Re: [Gimp-user] Definition of "project data" .... vs "image data" vs "workspace data"

[Jay Smith]

On 08/07/2012 05:32 PM, Alexandre Prokoudine wrote:

On Wed, Aug 8, 2012 at 1:10 AM, Rob Antonishen wrote:


And this is where your use case is wrong! The whole point of separating save
and export is that ONLY save is "safe".  An export is NOT guaranteed to be
either safe or lossless.  It may be,  depending on the source image.  Your
example exactly demonstrates the purpose of the new paradigm.


The main problem I see with the suggested use case is here:
"Transparancy lost. This is something I already encountered once, so
it is a realistic use case."

Excuse me, Anoko, but there's no way I'm going to believe that a
mistake that is only ever done once is going to completely ruin
everything. Especially since GIMP asks to save project data.

Alexandre Prokoudine



Splitting off to a different thread.

I have seen the term "project data" used in regard to XCF file format, 
as Alexandre has above.


However, to me, the XCF does not _currently_ really save what I consider 
to be the _project_ data.


Gimp does not save, to my knowledge (please excuse any errors), the 
following (and more, I am sure):


- window positions or sizes
- visible dialogs
- viewing magnification magnification
- active tool
- most recently applied filter
- most recently used settings in dialogs (such as Image Size settings
 such as inch vs mm etc.)
etc., etc.

Maybe these things are on the horizon, which would be great.

Still, when I think of a "project", I usually think of multiple images 
open at the same time, etc.


I don't know that "project" is a good word in this situation.  I would 
prefer "workspace".  But even if it is to be "project" it is more than 
just one image.


What I hope to see in the years to come is:

- Saving "image" includes saving the items listed above (and others) for 
a single image.


- Saving "workspace" (or "project") saves all "image" stuff mentioned 
above, for multiple images and whatever else is going on in Gimp at that 
moment.  Opening "workspace [name]" would open multiple images and 
everything would look exactly like it did when the workspace was saved.


(Or maybe "project" and "workspace" are completely different things??)

Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] HATE the new save vs. export behavior

[Jay Smith]

On 08/07/2012 05:52 PM, Alexandre Prokoudine wrote:


The usability team spent quite a while writing all the reasoning down
at gui.gimp.org. I don't really understand why we need yet another
long thread to go through all these things yet again.

Alexandre Prokoudine


Alexandre,

IMHO the answers to your (probably rhetorical) statement (which I take 
as more of a question) are fairly obvious...


Either the "writing" process was not complete and/or the needs and 
preferences of some users/workflows were either not considered, were 
considered and ignored as unimportant, or viewed as outside the target 
group of users.


As many husbands have taken decades to learn (or else they are no longer 
married), sometimes "writing all the reasoning down" won't make the wife 
feel better.  Right now, the developers are responding to an emotional 
situation by saying something like "but we did what was logical, we even 
wrote it down first".  In the recorded history of human relations, I 
doubt that response has worked on a regular, consistent basis.


Users become very attached to the software they use.  They start to 
think of it as "theirs".  They have made a very real investment in time, 
energy, learning, etc. to use the software.  Users also develop a "brand 
attachment" that is deeper than most product makers comprehend (users of 
products will often stick by a product that even they themselves 
complain about as being inferior -- sort of a Stockholm Syndrome in a 
different kind of way).


Software must evolve over time.  If the users need the features in the 
new software versions, then the users must evolve with it.  (Otherwise, 
the users have to set up Vmware and run old software on old operating 
systems -- I am still running one such program that I obtained in 1984 
because I still have not been able to find anything better for the very 
specialized task I use it for.)


When software evolves in a direction different from that user/workflow, 
the user experiences *very personal* feelings of *loss*.


The strong feelings expressed in all these "yet another long threads" 
are users expressing their feelings of _loss_.


And it is not just their _feelings_.  Some of them will decide that they 
will have to migrate to other software which does include them it its 
"target user group".  That migration comes at a very real cost of time, 
effort, learning, and perhaps money.


Every product, probably especially including software, must over time 
re-evaluate who its "target user group" is.  In doing so, if changes are 
made, then some previous _loyal_ users will be excluded.  Those users 
have done nothing "wrong" -- they just woke up one morning and found 
that they now live outside the walls of the city and there is nothing 
they can do about it.


If the developers have made a mistake, it was possibly overlooking these 
"feelings issues" and not expecting such a strong reaction.  That is not 
to say that the developers did not have to do what they did.  However, 
they should not have been surprised by the reaction.


*If* I recall correctly, for a short period of time before you 
(Alexandre) took on your current role of attempting to soften and 
humanize the communication, there was some rather harsh communication 
from the developer side that just poured salt in users' wounds.  Your 
involvement has made things better, though it seems that you are 
(understandably) getting tired.  THANK YOU FOR WHAT YOU HAVE BEEN 
DOING!


I just wish the developers would be open to conversation of how both 
types of workflows could be accommodated efficiently (both efficient for 
users and in the code).  Closing off that possibility of conversation is 
perhaps what hurts most of all.  I wish I had enough knowledge to 
contribute ideas of how to accomplish this while meeting the needs of all.


Jay
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

Re: [Gimp-user] HATE the new save vs. export behavior

[Jay Smith]

On 08/07/2012 04:59 PM, Anoko wrote:

On Tue, Aug 7, 2012 at 10:49 PM, Anoko wrote:



The explanation page says "In other words, GIMP used to assume
that you don't mind accidental loss of unrecoverable project data and
bothered you with confirmation dialogs. It was a convoluted logic,
but people got used to it."

I do not see why this is solved.



Yes, you don't see it :)


I understand that you are bored of the discussion, but by suggesting that it is 
my problem alone of seeing it wrong, I think that's a bit insulting and really 
unnecessary. I was at least trying to be constructive. I suspect though that 
you have misunderstood my use case.

User: lets say he wants so save image with transparance as jpg, clicks save
Gimp: you have to use export
User: Export to jpg
Gimp: ok! (no message that transparance got lost)
User: click exit
Gimp: Sure? not saved!
User: uh, I just exported it, oh yeah right exporting is not saving. But it's 
exported, so my changes are safe. Agree!
Transparancy lost. This is something I already encountered once, so it is a realistic use 
case (whether it is a probable is something else, but whether the previous 
"problem" was much larger is to be seen as well).

Since in the "old" workflow, everyone who used to use "save" for exporting to png/jpg etc., will 
with some annoyance now use export, but no longer get "flatten layers?" messages, and he/she has to remember 
that indeed "unsaved changes" are unrelated to exporting.

Since such people will always get a "you have unsaved changes" message when 
exitting the GIMP, this message becomes useless for this workflow. Thus, the only way to 
use GIMP without major annoyance, is to follow the forced xcf route.



Hi Anoko,

I am just another user like you.  I also don't like the new save/export 
model.


I wish that a mechanism could be found that solves these save/export 
issues for _both_ types of workflows.  However, the answer to that from 
the developers seems to have been that it is too hard and causes too 
much potential confusion / logic branching in the code, thus making 
future coding more difficult.  (So instead the users of one workflow 
type or the other have to do the work instead of the computer doing the 
work.)


However, IMHO the developers have _not_ misunderstood your use case and 
are _not_ overlooking the use case you describe.


Instead, IMHO they are not concerned about that use case.

It is all very strange to me.  On one hand, they developers were trying 
to avoid accidental loss of data by making the change that they made.


However, the use case you describe (which I can see happening to many 
people) does not, IMHO, seem to concern the developers because they 
_may_ be thinking that "only an amateur" would make that mistake and 
thus that is not of concern for Gimp because Gimp is really not an 
appropriate tool for amateurs and amateurs are not in the target user 
group that the developers are making Gimp for.


So, on one hand, the developers make a change to prevent users from 
losing data as a result of their own lack of knowledge or bad 
procedures.  On the other hand, the developers seem to ignore a 
situation (that you have described) which has the same result.


Either Gimp is for advanced users who won't have these problems (and 
don't need to be protected from themselves) or it is for a broader group 
of users that do need to have some protection from themselves.  Pick one.


IMHO, the "loss of data" situation that the developers were trying to 
prevent with this change was not serious problem for the Gimp target 
user group (advanced users).  I doubt those advanced users were having a 
problem before this change.  I suspect that the people who were having 
the problem is the very group that are still going to have a problem in 
the use case you described.


When all the arguments about this got "loud", I expressed my opinion 
that protecting users from their own ignorance and bad procedures just 
enabled users to be ignorant and use bad procedures.  My opinion was/is 
that learning is (along with many other factors) a result of making 
errors, paying the price and thus learning.


We evolve by learning.  We learn as the result of experiences.  Take 
away some of the bad experiences and you reduce the opportunities for 
learning.


The developers jumped on me like I had five horns growing out of my 
head.  I got emails that called me bad names and suggested that I was a 
terrible person because I would allow somebody to suffer just so that 
they would learn something.  (In response, I say that a person will 
suffer a whole lifetime if they don't learn some hard lessons -- the 
faster they do that learning, the sooner their life will get easier.)



In the end, however, I wish that a mechanism could be found that solves 
these save/export issues for _both_ types of workflows.


99% of my use is open TIFF, edit TIFF, save TIFF, close TIFF.  99% of 
the time, I have absolutely no need for retai

Re: [Gimp-user] Reply via List Headers [was: Re: Calm and rational Save/Export workflow report ; )]

[Jay Smith]

On 05/11/2012 09:39 AM, Michael Schumacher wrote:

Von: Richard Gitschlag



Then the real question is why every time I hit Reply, Hotmail prefills my
form with the individual user's email instead of the mailing list's, and I
have to change it every time before hitting Send.  GIMP or otherwise,
minor impediments like these are quite annoying.


That probably happens because Hotmail doesn't handle the List headers that are 
part of each message, e.g.:

List-Id: GIMP Developer List
List-Unsubscribe:,
List-Archive:
List-Post:
List-Help:
List-Subscribe:,


It should be rather easy for Hotmail's developers with their near limitless 
resources to implement a List Reply feature (or make Reply behave differently 
for list mails, although this may break other users' expectations). Additional 
features like links to the archive, unsubscribe or subscribe would be possible 
as well.

HTH,
Michael


Michael,

I use Thunderbird 3.1.10 -- not the latest version, but quite happy with 
it.  This version of Thunderbird does the same thing (replies to the 
individual poster, instead of the list).


In the last few years, the Gimp lists are the _only_ lists I receive 
that result in this behavior.


Jay


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

Re: [Gimp-user] QUESTION OF ETHICS

[Jay Smith]

On 05/10/2012 04:26 PM, Russ Marshall wrote:

Can anyone explain to me why GIMP allows their “FREE” software to be
SOLD on eBay? There are those of us
who have been cheated by sellers who, when you win the auction send you
the URL for GIMP web page where
you may download it for free
I have complained to eBay but they will not do anything about it.
RUSS MARSHALL



Russ,

Gimp developers do not "allow" or "not allow" sales.  The Gimp license 
does not prevent such activity.  That is part of the whole open-source 
software world, it is not related only to Gimp.


No, such activity is not honorable -- if the seller has not added any 
value to transaction, but since it is not a disallowed activity, it is 
not illegal.  Whether it is ethical or not is a decision above my pay 
grade.  I don't like it, but even vultures and possums have their role 
in the world.


However... I believe strongly -- and I do apply this thinking to myself 
as well -- that one should first look to oneself before deciding to 
blame others.  Did you know that you were buying Gimp?  Did you know 
what you were going to be receiving?  If you did know that you were 
buying Gimp, did you research it (doing a simple Google search would 
have told you everything) before bidding on it.  Or, if you did not know 
what product you were buying, why did you bid on it?  All these types of 
questions should perhaps be considered before blaming everybody else.


If you were not previously aware of Gimp and you did not do any research 
to find Gimp (or other free / open-source software), then perhaps the 
eBay seller did actually provide some value for the price they charged 
-- in a devious kind of way, they have introduced you to the wonderful 
world of Gimp.  If Gimp cost $200 or $500, it would still be worth it to 
_many_ people, myself included.


So, perhaps this is just a life lesson:  Know exactly what you are 
bidding on, research alternative sources before bidding, etc., etc.


By the way, there is a huge and wonderful world of free / open-source 
software around there.  Explore that world and you will find a lot of 
great, free programs you had no idea existed.


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

Re: [Gimp-user] HATE the new save vs. export behavior

[Jay Smith]

On 05/05/2012 10:30 AM, Alexandre Prokoudine wrote:

On Sat, May 5, 2012 at 12:21 PM, Ken Warner wrote:


but many posts calling for civility have come from people who want to divide
the user base into two groups where one group is somehow more entitled to
use GIMP than the other because of the things they do with GIMP.


You know, it's quite frustrating that after all the explanations
people still seem to get this wrong. So let's try again.

We are not separating people into better of worse users, or the
deserving and non-deserving, or entitled and not entitled. This would
not be a constructive approach.

What we _are_ doing is _focusing_ on a group of users who are
underloved by free software. We are building workflows around their
needs. We are _targeting_ those users.

Maybe not everyone can see the difference, but it's right there. Hence
attributing any kind of discrimination to us would be utterly wrong. I
wish people really stopped doing that.

Alexandre Prokoudine
http://libregraphicsworld.org



Alexandre,

Please allow me a few words...

a) The users whose workflow has been made more difficult are 
_understandably_ upset.  They were using a program in a certain way that 
worked well for them.  However, either unknown to them (maybe they 
should have been paying more attention?) the focus of the developers 
changed/evolved over time in a way that is not helpful to those users 
AND/OR those users simply did not realize (months and years ago) that 
they were using a program that was going to move away from the way in 
which they were using it.


   Part of what seems to be missing here is humility and respect on the 
part of the developers ... would it be too hard to simply say "We are 
sorry ... even though we are the ones doing the work and we have chosen 
to go in a particular direction, WE ARE SORRY!"  Sometimes those simple 
words can go a very long way.  It is like saying "I am sorry for your 
loss"... there is not a darn thing that I can do about the fact that 
Uncle Harold has died, but I _am_ sorry that it has happened and that 
your life will change as a result.


   On the other side, however, the upset users have not, IMHO, shown 
adequate understanding or appreciation for what the developers have 
GIVEN to them over the years.  Maybe it is a case of a good thing that 
must come to an end for certain users.


b) The users could have paid more attention to the conversations the 
developers were having ... I am an "ordinary" user and *I* knew this was 
coming because I monitor the developer list.


c) The developers UTTERLY FAILED to manage public relations on this.  It 
was completely obvious to me (from monitoring the discussions on the 
developer list) that this subject was going to touch of an enormous 
storm of anger among some users.


   If the developers don't like the angry reaction they have received, 
perhaps the developers should examine how they could have done a better 
job of communication ON THE USER LISTS to warn people of what was 
coming.  I am not saying "ask", I am saying "warn".


   In what I have observed over the years as rather typical attitude by 
open-source developers, the developers did not seem to think about (and 
certainly did not execute) good ADVANCE public relations on this 
subject.  The attitude of "we did it, like it or leave it" is just not 
well received in this day and age.


   At the same time, users must understand that the developers are 
(despite what the developers might think), only human.  They are 
fallible.  They screw up.  They make bad decisions.  However, the 
developers are the ones doing the work  Anybody that does not like 
the direction that an open-source program is going can branch off and do 
their own work.  I know that 99.99% of users, like me, do not have the 
skills to do that, but that is the price we users pay for using free 
software.


   Users of open-software have an extremely high loyalty and commitment 
to the particular software they use.  They feel that it is "theirs". 
That they "own" it.  That is all well and good until the software goes 
in a direction that is different from where the user wants it to go -- 
when that happens, there is great anger because there is great emotional 
loss.  Developers have a responsibility to at least understand this 
concept and to attempt to mitigate users' feelings of loss and to 
prepare them in advance for inevitable changes.


   If developers don't feel that they have such a "responsibility" -- 
which would be a reasonable opinion on a developer's part -- the 
developer must accept the anger that will come.  It is inevitable; 
thinking otherwise is unsound.


d) As I said, I monitored, and participated a bit, in the developer 
discussion about save/export when implementation was being discussed. I 
described my workflow and how the proposed change would negatively 
affect me and users like me.


   At that time export may have been part of the goals for the program, 
bu

Re: [Gimp-user] HATE the new save vs. export behavior

[Jay Smith]

On 05/02/2012 08:45 PM, Jonathan Kamens wrote:

New way:

   1. "gimp file.jpg".
   2. Make changes.
   3. Open File menu and select "Overwrite" (no keyboard shortcut for
  that!).
   4. Periodically type ctrl-e to save further progress (because for
  some inexplicable reason, once you use the "Overwrite" command it
  disappears and is replaced with the "Export" command which appears
  to do exactly the same thing, but /this/ one has a keyboard
  shortcut; how does that make sense, exactly)?


Jonathan, I hope that you realized that when editing a JPG, repeatedly 
saving/exporting to JPG (your step 4) reduces the quality (actually 
compresses / deletes data).  Maybe this has been working for what you 
are doing, but I beleive it is contrary to what most users do -- because 
they don't want to diminish quality/data.



   5. Type ctrl-q.
   6. GIMP tells me I have unsaved changes, even though I just saved
  them with ctrl-e.
   7. Click "Discard Changes" to really exit.

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

Re: [Gimp-user] Seeking better "green screen" method

[Jay Smith]

On 01/17/2012 03:29 PM, Chris Mohler wrote:

On Tue, Jan 17, 2012 at 2:17 PM, Jay Smith  wrote:

Goal:

To be able to select the background (for change to 100% black) without any
"leakage" of the selection onto the stamp objects AND without ANY non-black
color artifacts remaining after changing the selection to 100% black.


Question: have you tried scanning with a dark-as-possible background*
and then doing 'Colors-Levels' and dragging the right-hand slider over
until the background is "solid black"?


Yes to "dark as possible" (and not shiny)

No to "Colors-Levels".  The problem in that operation is that it 
would also affect the related black areas in the postmarks on the stamp. 
 The color of the postmarks should not be darkened as it would change 
the appearance of the image (which are actual items that people are 
expecting to appear in the image as they are in real life).



Also, the "halo" may be a result of the height of the objects/stamps -
have you tried adding weight on top of the objects to get them as flat
as possible?


I agree that height/thickness is part of the problem.  Yes, we have 
added weight with no affect on most items.


Please note that the "weather person standing in front of a weather map" 
has not only their own thickness, but a foot or two between them and the 
map.  If the room lighting is not 100% right, one can see a bit of 
"green screen shadow", but 99% of the time there is no shadow and no 
halo.  I am hoping that level of success can be achieved in what I am 
trying to do.


Thank you Chris.

Jay



Chris

* something black, with a non-reflective surface.

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

[Gimp-user] Seeking better "green screen" method

[Jay Smith]

Hi,

Gimp 2.6.6 on Ubuntu Linux 8.04.

Scanning using VueScan Professional 8.5.20 with an "Epson Perfection 
4490 Photo" scanner.  Color profile has been built for the scanner using 
available photo color target from a well-known German source (can't 
remember name).


Almost all my scanning is of postage stamps and related items -- 
scanning the actual physical objects, not photos of the objects.


Problem:

The stamps are currently scanned on a black background (for lack of 
other color possibilities; the final goal is on a black background). 
After scanning, the background is selected and turned to 100% black to 
have greatest contrast for the object.  When a stamp has a postmark that 
crosses the edge of the stamp paper, the color of the postmark (usually 
dark or black) is very close to the color of the scanning background and 
thus when the background is selected, the selection "leaks" and 
"follows" the postmark onto the stamp.  We have to manually exclude 
those "leaks" from the desired selection area.


Goal:

To be able to select the background (for change to 100% black) without 
any "leakage" of the selection onto the stamp objects AND without ANY 
non-black color artifacts remaining after changing the selection to 100% 
black.


Attempted Solutions:

We have tried scanning on many different non-black background colors and 
surfaces, but there are always some extreme-edge color artifacts 
remaining ... leaving a sort of "halo" effect around the stamp object.


Some of this could be attributable to the particular model of scanner, 
though every scanner I have ever owned had a similar problem to a 
greater or lesser degree.  The width of the "halo" usually depends upon 
which side of the object it is on vs the direction of travel of the 
scanner device.



In television broadcasting it is extremely common for somebody to stand 
in front of a "green screen" and for the green to be electronically 
replaced with some image or video, etc.  (For example, the weather 
person standing in front of a weather map.)  It is rare to see a green 
"halo" if everything has been done correctly and if the person is 
wearing the correct type of clothing fabric.


Is there some Gimp method or plug-in or other tool that will better 
handle this type of use?


Recently poster Ron Guilmette discussed his use of 
"Darla-PurpleFringe.scm" plug-in to remove an artifact caused by a 
digital camera and subsequent processing.


Is there something like that which can be used to remove a color "halo" 
that results from using a "green screen" approach to scanning?  (I would 
likely have to select different colors of "green screen" so that such 
colors are not included in the design of the postage stamp.


Any advice would be appreciated.

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

Re: [Gimp-user] Fix Orientation ?

[Jay Smith]

On 01/09/2012 04:10 PM, Ronald F. Guilmette wrote:

What is the proper way, using gimp, to correct the orientation of an
image?

For example, I just took a shot with one of my cameras where I was
holding the camera in a vertical (portrait) orientation.  But when I
transfer the .JPG to my PeeCee and view it with gimp (or ImageMagick)
it is laying over on its sid, in landscape orientation.

To fix this, should I be using Tools->Transform Tools->Rotate or is
there a better way?  (Actually, I did try doing it that way using
gimp, and the results were distinctly unacceptable... some parts of
the image got cropped out, and some new transparent parts were added.
Bummer.  This is not at all what I had in mind.)


Regards,
rfg


P.S.  Before asking here, I did try googling around for gimp and
"orientation" and/or gimp and "rotate" but didn't find anything
enlightening.  I also checked the Gimp FAQ and again came up empty.


Ron,

When I started using Gimp, rotation (arbitrary) was a big problem for me.


If you wanting to rotate in 90 degree increments, then use (as others 
have already posted)


   Image, Transform, [and select the operation you want]

That will take care of the problem you are having.


On the other hand if you want to do arbitrary or automatically 
calculated degrees of rotation, the method you used is correct, HOWEVER, 
you first must expand the canvas:


a) In some cases you may wish to set the background color.  That is in 
the Toolbox (Windows, Toolbox) ... you can set foreground/background 
colors and/or reverse them, etc.  When you expand the canvas, it will 
automatically fill with the background color you have specified, thus 
the potential importance of this step.


b) To expand canvas:

   Image, Canvas Size
   FIRST AT THE BOTTOM IN "Layers: Resize Layers" CHANGE TO "ALL LAYERS"
   (That is a major Gimp Annoyance.)
   Then enter your desired new canvas size and then move out of that
 field for it to take affect.
   NOTE that once you have entered the new canvas size but are still in
 that dialog, you can drag the preview image around in the canvas
 to put it roughly where you want it.

c) Then do your Tools->Transform Tools->Rotate.

Learning to use the Arbitrary or Automatically Calculated Rotation tool 
takes some experimentation (at the bottom your Toolbox there should be a 
variety of options for its behavior).  Once you figure it out, it is 
extremely powerful.


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

Re: [Gimp-user] Problem with the Newsprint filter?

[Jay Smith]

On 01/09/2012 10:00 AM, Zweibaby wrote:

So, yesterday I was trying to halftone an image.  Everything was working fine, 
but I couldn't figure out how to use it the way I wanted to.  So I found a 
tutorial.  I read it, figured out what I was doing wrong, went on my way.  
Everything seemed fine.



Then I went to use my newfound knowledge, and lo and behold, the Newsprint 
filter stopped working.  No matter what I tried, the preview image looked just 
like the original.  And when I tried applying the filter anyway, figuring maybe 
something was just up with the preview panel, nothing happened.  The filter 
pauses to load when I change something, acting like it's working, but nothing 
happens.  The closest thing I've been able to get was the image completely 
disappearing when I change a certain setting (switch to intensity, in case you 
were wondering).  I tried googling my problem, but all that gets me is 
tutorials and the how-to-use guide.  I was hoping someone here would know 
what's wrong and how to fix it.



Thanks in advance!


Well, I got it to sort-of work now.  It's not exactly how I want it, and I 
still haven't figured out how it suddenly switched the way it wanted to work, 
but I pieced something together.  I'd still like to know why it did what it 
did, though.


Is it possible that your image has multiple layers and that 
(unknowingly) you were trying to use the filter on a layer for which the 
filter would have no effect?


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