GIMP

Hi Floyd,
Hanz wrote:
Sure. For serious image processing you need signed integer, float and
complex data types. GIMP was not designed for that, not sure about PS.

That is not quite true. GIMP of course *does* use all
of those data types where appropriate for precision and
accuracy of arithmetic.
Yes, but if the result of an operation requires a sign or requires float
precision and you want to link up or combine a couple of these
operations on the script or GUI level, as I understand it you have a
problem with the GIMP.

That has very little to do with the image format bit
depth.
It has when you need that format to store results of operations in order
to link them.

I guess the problem for GIMP that everything ever written for it, and
that is a lot, assumes a byte type, and will have to be rewritten or at
least reviewed in order to be used for other data types. A difficult
thing in an open source community.

That is in fact the currect "project" underway with the
development of GIMP.
Yep.

It should also be noted that /cinepaint/, an offshoot of
GIMP, has had 16 bit depth image format capability for
years.
Have to check that out..

It isn't actually a horribly difficult implementation,
but given that it actually doesn't have that much
significance it simply was not a priority until many
other functionalities were finished.
I think considering the amount of tools in the GIMP it is a serious
amount of work, especially if code was not written with different data
types in mind.
But agreed, the major problem people have with the GIMP is probably the
amount of windows you get on the screen, and the resulting confusion.
That has improved much the last years.

In what way? I don't understand what you intend to say
there.
Try for example multiple color and Level-tool corrections, and look at
the posterization effects, ugly. Best do it in one stroke and then
right. Doesn't add to the user friendliness.

Still, if you do not stack up too much operations,

That one is not really valid.

and make sure major
color and contrast corrections are done elsewhere, GIMP is fine for
final color adjustment, resampling, mild USM, masking flare, perspective
correction, and so on.

Exactly. (And even when it has 16 bit depth image data,
it will not change any of that... "Major color and
contrast corrections" should be done with the RAW
conversion program.)
That will require you to go back to the converter or scanning program in
case of a mistake, not so nice, chases users away.

Just my 2 cts! Hans

Hanz wrote:
Hi Floyd,
Hanz wrote:
Sure. For serious image processing you need signed integer, float and
complex data types. GIMP was not designed for that, not sure about PS.
That is not quite true. GIMP of course *does* use all
of those data types where appropriate for precision and
accuracy of arithmetic.
Yes, but if the result of an operation requires a sign or requires float
precision and you want to link up or combine a couple of these
operations on the script or GUI level, as I understand it you have a
problem with the GIMP.

Scripts can also use *all* of those data types.

GIMP scripts are written in either Scheme (an
exceedingly bare version of Scheme) or Python.

That has very little to do with the image format bit
depth.
It has when you need that format to store results of operations in order
to link them.

Something you *don't* need.

But agreed, the major problem people have with the GIMP is probably the
amount of windows you get on the screen, and the resulting confusion.
That has improved much the last years.

Giggle snort. If people have an OS with a reasonable
windowing system that is not a problem. GIMP of course is
written with X11 in mind, and of course it is quite nice.
Doubly true if one used dual monitors...

You have deleted the text preceeding the following question.
Let me re-insert it:


The operations inside the USM algorithm could be done with higher
precision without loss of speed, but final storage is a limiting factor.

And my response was:

In what way? I don't understand what you intend to say
there.

And your response is:

Try for example multiple color and Level-tool corrections, and look at
the posterization effects, ugly. Best do it in one stroke and then
right. Doesn't add to the user friendliness.

That's BS mate. If you are saying it will look
different if done as one operation than it will look if
done as multiple operations, that is simply untrue.
Perhaps if you divided it into 1000 distinct operation,
but that would be absurd.

Exactly. (And even when it has 16 bit depth image
data,
it will not change any of that... "Major color and
contrast corrections" should be done with the RAW
conversion program.)
That will require you to go back to the converter or scanning program in
case of a mistake, not so nice, chases users away.

If you make a "major" mistake, that is what should be
done *regardless*. It has nothing to do with GIMP.

--
Floyd L. Davidson http://www.apaflo.com/floyd_davidson
Ukpeagvik (Barrow, Alaska)

Hi Floyd,

Scripts can also use *all* of those data types.

GIMP scripts are written in either Scheme (an
exceedingly bare version of Scheme) or Python.
That's the glue language, you hardly ever deal with pixel data there.
I'm talking about storing intermediate result images. Think FFTs on
which you want to apply operations from the GIMP toolbox.



Giggle snort. If people have an OS with a reasonable
windowing system that is not a problem. GIMP of course is
written with X11 in mind, and of course it is quite nice.
Doubly true if one used dual monitors...
To gain substantial audience you need to cater to what people are used
too, that means OSX-aqua, Windows. OSX-X11 is not good enough, for Mac
people.

You have deleted the text preceeding the following question.
Let me re-insert it:


The operations inside the USM algorithm could be done with higher
precision without loss of speed, but final storage is a limiting factor.

And my response was:

In what way? I don't understand what you intend to say
there.

And your response is:

Try for example multiple color and Level-tool corrections, and look at
the posterization effects, ugly. Best do it in one stroke and then
right. Doesn't add to the user friendliness.

That's BS mate. If you are saying it will look
different if done as one operation than it will look if
done as multiple operations, that is simply untrue.
Perhaps if you divided it into 1000 distinct operation,
but that would be absurd.
The problem from which posterization arises is that during mapping
operations like color, contrast corrections and so on multiple component
values in a channel get mapped into one value. After that you can't
separate them anymore. Try sqr(sqrt(image)), where each operation stores
the results in bytes, you'll end up with an image with 16 different
values. That happens too with say 32bit integer operations, but if for
final output (viewing, printing) that matters less because the precision
needed there is less. And in cases when that does matter, use floats.

Exactly. (And even when it has 16 bit depth image
data,
it will not change any of that... "Major color and
contrast corrections" should be done with the RAW
conversion program.)
That will require you to go back to the converter or scanning program in
case of a mistake, not so nice, chases users away.

If you make a "major" mistake, that is what should be
done *regardless*. It has nothing to do with GIMP.
True, but this strict attitude won't gain you friends.
Let me put it this way: authors of open source software like their
software to be *used*. That means that they'll have to listen to what
people think about their stuff, otherwise the project dies. This holds
also for commercial software developers, with an obvious penalty if they
don't. This NG is an excellent place to learn what serious (well...)
photographers think.
Best road from here is to start contributing to the GIMP
http://developer.gimp.org/

-- Hans

On Wed, 03 Sep 2008 17:53:13, Floyd L. Davidson wrote:
Alan Browne wrote:
Hanz wrote:
snipped

Not sure why you reposted all that w/o adding to it. But the plain fact
is this: where processing takes place with 8b/c v 16 b/c, successive
operations are definitely going to cause more damage to the coarser data
than to the finer data. That is why Gimp is compromised (We'll see how

That is BS and simply is not true. The "successive
operations" are done with 32 bit integer arithmetic.

Alan Browne's point is that even though the operations are done with
high-bit arithmetic, after each operation, GIMP reduces back to an
8-bit representation. Whereas many equivalent operations in Photoshop
can stay in 16-bit representations.

That said, I use GIMP for what little photo editing I need, but this
is a real limitation that can affect output in a way that can be
unacceptible to some users.

-a

--
Alan Hoyle - - http://www.alanhoyle.com/

Troy Piggins wrote:

Here's my first test post with the keyboard described above
plugged in:

lkasdgpqngq uiqh qhipugq ipqhf q;a;09358 ap[idhf a908dyf -98dt31
aoiuy39yu1`9 `8p9Hih
yti43q9-ut ap9fg ad340985645w asd4g64aoit0439)(*)(*^&)(*#y4 3p29y

Clearest thing you've said in weeks.


--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: Remove FreeLunch.
-- usenet posts from gmail.com and googlemail.com are filtered out.

* Alan Browne wrote :
Troy Piggins wrote:

Here's my first test post with the keyboard described above
plugged in:

lkasdgpqngq uiqh qhipugq ipqhf q;a;09358 ap[idhf a908dyf -98dt31
aoiuy39yu1`9 `8p9Hih
yti43q9-ut ap9fg ad340985645w asd4g64aoit0439)(*)(*^&)(*#y4 3p29y

Clearest thing you've said in weeks.

7we% nos



--
Troy Piggins
I always appreciate critique.

Floyd L. Davidson wrote:

GIMP scripts are written in either Scheme (an
exceedingly bare version of Scheme)

Bare in what way? Scheme is bare by design (Schemers get a
lot out of the fact that the CL (Common Lisp) language's *index*
is longer than their wole language definition).

or Python.

Perl. You're missing perl here.

-Wolfgang

Troy Piggins wrote:
* Alan Browne wrote :
Troy Piggins wrote:
Here's my first test post with the keyboard described above
plugged in:

lkasdgpqngq uiqh qhipugq ipqhf q;a;09358 ap[idhf a908dyf -98dt31
aoiuy39yu1`9 `8p9Hih
yti43q9-ut ap9fg ad340985645w asd4g64aoit0439)(*)(*^&)(*#y4 3p29y
Clearest thing you've said in weeks.

7we% nos

ljs34^ jbhew jdsdjm, njasd [kasdh] !! )-8

--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: Remove FreeLunch.
-- usenet posts from gmail.com and googlemail.com are filtered out.

Alan Browne wrote:

For light editing this is not a huge deal, I admit, but it does make
changing contrast/bright/colors, etc. a lossy deal.

With finite number of bits and infinite possible values,
everything is lossy.

The USM is ________HORRIBLE________

Gimp comes with source. (It also accepts plugins.) You can
0) find out *exactly* and *definitely* what Gimp does
1) roll your own USM
2) Use a series of operations to get the sharpening you prefer
(that's what I did, using layers and layer masks created
on contrasts, i.e. sharpen medium styrong borders most)
3) use layers and masks to quickly reduce the strength of
your operation
4) pay someone to do the changes you require.
5) pass on the changes, even charge for passing them on

Wake me when PS allows things like that.

a) The preview is on a tiny area of the scene

Resize the dialog box.
Too easy? OK, just copy the layer, USM it strong enough,
back down with the layer opacity slider. Fine-adjust with a
layer mask, if necessary.

2 layers with opacity and mask being adjusted doesn't tax even
low-end CPUs --- not even full screen.

That method may even work in PS.

and you have to move
sliders around to select an area (imagine a 8500 x 8500 pixel image and
preview area of approx 200x200 and you want to check for detail and
halos at a dozen places... Oh my... crap!

Yes, doing a 20-second exposure handheld is "Oh my... crap!",
but that's still not the camera's fault. It is an operator
error, even if said operator usd a steadycam.

b) and then the results of the USM are just plain terrible compared to
those in photoshop.

USM is USM, so it must be your fault, right?

-Wolfgang

Alan Browne wrote:

In PS CS3, a very light touch USM on an area of fine detail worked
fine. Identical settings (emphasis is on _light_) in gimp

Identical? You don't even know the σ (sigma) which PS CS3
applies, so how can you even think to be sure that's identical with
the one Gimp's USM uses! (And no, I'm not BSsing you, go look
at Image Magick, where you can set that parameter. With Gimp,
the source will tell you the σ (and allow you to change it).
With PS ...)

-Wolfgang