GIMP

Floyd L. Davidson wrote:
Go back to school.

Always. And when I wrote s/w for a living, including the sampling and
realtime synthesis of complex signals in assembler, minding resolution
in computations to avoid such effects was always on my mind. That's why
the whole notion of editing images captured at 12 - 16 bits resolution
at 8 bits is laughably stupid... and the folks who manage the gimp
project appear to think so too... see below.

If *you* are oversharpening, that is *not* the fault of the
tool.

I explained quite clearly that I don't oversharpen. Twice. My
statements were about the detection of over sharpening so it can be
avoided. Really, try a different tack or even reading.

But here's some quotes for you:

""Once GEGL integration is complete, GIMP will finally get support for
higher color depths, more color spaces and eventually non-destructive
editing.""
http://gimp.org/release-notes/gimp-2.5.html

""What's New in GIMP 2.5

UI changes

GIMP has several UI changes in this version, many of them offering
relief to long standing issues.""




--
-- 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:
Floyd L. Davidson wrote:
Go back to school.

Always. And when I wrote s/w for a living, including the sampling and
realtime synthesis of complex signals in assembler, minding resolution
in computations to avoid such effects was always on my mind. That's why
the whole notion of editing images captured at 12 - 16 bits resolution
at 8 bits is laughably stupid... and the folks who manage the gimp
project appear to think so too... see below.

If *you* are oversharpening, that is *not* the fault of the
tool.

I explained quite clearly that I don't oversharpen. Twice. My
statements were about the detection of over sharpening so it can be
avoided. Really, try a different tack or even reading.

But here's some quotes for you:

""Once GEGL integration is complete, GIMP will finally get support for
higher color depths, more color spaces and eventually non-destructive
editing.""
http://gimp.org/release-notes/gimp-2.5.html

""What's New in GIMP 2.5

UI changes

GIMP has several UI changes in this version, many of them offering
relief to long standing issues.""


PS: Thanks to John A. for that tip.


--
-- 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:
Floyd L. Davidson wrote:

Obviously it is not for everyone... *you* should
stick with
"simple" integers and interfaces both.

What a laugh. You lose and try to damn me for your simple stupidity.

Here it is again. 1/256 resolution data after many manipulations will
have a lot of truncation/rounding errors compared to 1/65536 data going
through the same manipulations.

Even *you* can understand that except when you're trying to save $100.

Even you can understand that after you get done with all the
above, *you* "render" your images into 8-bit JPEG, and in the
process lose *all* of the accuracy/precision that 16 bit
processing maintained for you.

BTW, what makes you think that an 8 bit image format means the
math is done using 8 bits (or 16 for that matter) on a 32 bit
processor?

Duck Alan, here comes the clue-by-four...

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

Alan Browne wrote:
Floyd L. Davidson wrote:
Go back to school.

Always. And when I wrote s/w for a living, including the sampling and
realtime synthesis of complex signals in assembler, minding resolution
in computations to avoid such effects was always on my mind. That's why
the whole notion of editing images captured at 12 - 16 bits resolution
at 8 bits is laughably stupid... and the folks who manage the gimp
project appear to think so too... see below.

Your quotes below say no such thing.

If *you* are oversharpening, that is *not* the fault of the
tool.

I explained quite clearly that I don't oversharpen. Twice. My

You explained very clearly that you were oversharpening *in* *your*
*opinion*.

statements were about the detection of over sharpening so it can be
avoided. Really, try a different tack or even reading.

But here's some quotes for you:

""Once GEGL integration is complete, GIMP will finally get support for
higher color depths, more color spaces and eventually non-destructive
editing.""
http://gimp.org/release-notes/gimp-2.5.html

""What's New in GIMP 2.5

UI changes

GIMP has several UI changes in this version, many of them offering
relief to long standing issues.""

So things that the development team has thought 1) need to be
addressed, 2) some day, are in your opinion priorities now that
GIMP is several years old and the development team has gotten
down to the least important items on the priority list.

You don't understand that any better than you do quantization
distortion.

(BTW, I've been using GIMP 2.5 for awhile...)

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

Floyd L. Davidson wrote:
Alan Browne wrote:
Floyd L. Davidson wrote:

Obviously it is not for everyone... *you* should
stick with
"simple" integers and interfaces both.
What a laugh. You lose and try to damn me for your simple stupidity.

Here it is again. 1/256 resolution data after many manipulations will
have a lot of truncation/rounding errors compared to 1/65536 data going
through the same manipulations.

Even *you* can understand that except when you're trying to save $100.

Even you can understand that after you get done with all the
above, *you* "render" your images into 8-bit JPEG, and in the
process lose *all* of the accuracy/precision that 16 bit
processing maintained for you.

BTW, what makes you think that an 8 bit image format means the
math is done using 8 bits (or 16 for that matter) on a 32 bit
processor?

Oh dear. And what happens to a piece of information that has 10's of
operations performed on it? Are you going to do that at higher or
lower precision to conserve information?

The whole notion of higher precision arithmetic is to conserve precision
so that the output is as little affected as possible.

One wants all the rounding to occur in the lower order bits to preserve
the information over many manipulations to the data ... before
truncation, rounding or (especially) compression.

Your defense of the absurd is puzzling.

These clues should hit you, but there seems to be little of substance to
hit...

And of course the Gimp managers seem to see this too ... and are on the
way to a higher precision model... what *will* you do?

--
-- 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.

Floyd L. Davidson wrote:
Alan Browne wrote:
Floyd L. Davidson wrote:
Go back to school.
Always. And when I wrote s/w for a living, including the sampling and
realtime synthesis of complex signals in assembler, minding resolution
in computations to avoid such effects was always on my mind. That's why
the whole notion of editing images captured at 12 - 16 bits resolution
at 8 bits is laughably stupid... and the folks who manage the gimp
project appear to think so too... see below.

Your quotes below say no such thing.

If *you* are oversharpening, that is *not* the fault of the
tool.
I explained quite clearly that I don't oversharpen. Twice. My

You explained very clearly that you were oversharpening *in* *your*
*opinion*.

sigh I explained that I examined for halos to detect oversharpening.

I know part of your arsenal for usenet argument is to attack your
adversary (as adversarial is your approach to everything), but really
this is so low through repetition as to be exceeding tedious.

Last time: I do not oversharpen; I look for halos for the avoidance of
it. Is that clear enough?

statements were about the detection of over sharpening so it can be
avoided. Really, try a different tack or even reading.

But here's some quotes for you:

""Once GEGL integration is complete, GIMP will finally get support for
higher color depths, more color spaces and eventually non-destructive
editing.""
http://gimp.org/release-notes/gimp-2.5.html

""What's New in GIMP 2.5

UI changes

GIMP has several UI changes in this version, many of them offering
relief to long standing issues.""

So things that the development team has thought 1) need to be
addressed, 2) some day, are in your opinion priorities now that
GIMP is several years old and the development team has gotten
down to the least important items on the priority list.

Down to the most inconvenient to implement, you mean.

You don't understand that any better than you do quantization
distortion.

I understand quantization error more than enough for these purposes. I
also know it is not limited to sampling.

You don't understand what happens to numbers that go through many
processing steps, losing information as they go unless they are
represented by adequately large number spaces.


(BTW, I've been using GIMP 2.5 for awhile...)

In 8 b/c mode I hope.




--
-- 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:

Oh dear. And what happens to a piece of information that has 10's of
operations performed on it? Are you going to do that at higher or
lower precision to conserve information?

The whole notion of higher precision arithmetic is to conserve precision
so that the output is as little affected as possible.

One wants all the rounding to occur in the lower order bits to preserve
the information over many manipulations to the data ... before
truncation, rounding or (especially) compression.

Your defense of the absurd is puzzling.

To you, no doubt!

An 8 bit depth image format does not mean the math for various
operations is performed using 8 bit precision, in particular
with a 32 or 64 bit CPU.

Stop being silly.

These clues should hit you, but there seems to be little of substance to
hit...

And of course the Gimp managers seem to see this too ... and are on the
way to a higher precision model... what *will* you do?

You seem to ascribe something there that isn't.

16 an 32 bit depth will be useful. It isn't worth the several
hundreds of dollars that you have had to pay to get it over the
past several years.

It happens that when 16 bit depth is needed, I use /cinepaint/.
In a few months I'll just continue using GIMP. The point is
that it is simply no big deal. I will *still* do the things
that are best done with the RAW conversion program at that step
rather than in GIMP.

You, of course, can buy another upgrade from Adobe! It does
have, apparently, a simpler interface that you can deal with.

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

In article , Floyd L. Davidson
wrote:

a) The preview is on a tiny area of the scene 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!

Thank goodness for that! Instead of waiting while it applies
USM to your imaginary 72MP image, you only have to wait while it
does a 200x200 image. That allows you to very precisely adjust
for the correct USM.

what waiting? photoshop and camera raw's preview is real time on the
full displayed image, regardless of its size. i've yet to find one
where it lags. the same cannot be said for the gimp.

Really, I wish the Gimp folks well, but it is not something anyone
serious about photography would use. Get Elements for much better
results and get CS3 for heavy lifting.

The fact that you can't use it properly does not indicate a flaw
with the program.

ah yes, blame the user.

nospam wrote:
In article , Floyd L. Davidson
wrote:

a) The preview is on a tiny area of the scene 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!
Thank goodness for that! Instead of waiting while it applies
USM to your imaginary 72MP image, you only have to wait while it
does a 200x200 image. That allows you to very precisely adjust
for the correct USM.

what waiting? photoshop and camera raw's preview is real time on the
full displayed image, regardless of its size. i've yet to find one
where it lags. the same cannot be said for the gimp.

Really, I wish the Gimp folks well, but it is not something anyone
serious about photography would use. Get Elements for much better
results and get CS3 for heavy lifting.
The fact that you can't use it properly does not indicate a flaw
with the program.

ah yes, blame the user.

Oh glad you're here, I'm tired of arguing with these idiots.

Have fun.


--
-- 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:
Floyd L. Davidson wrote:
Alan Browne wrote:
Floyd L. Davidson wrote:
Go back to school.
Always. And when I wrote s/w for a living, including the sampling and
realtime synthesis of complex signals in assembler, minding resolution
in computations to avoid such effects was always on my mind. That's why
the whole notion of editing images captured at 12 - 16 bits resolution
at 8 bits is laughably stupid... and the folks who manage the gimp
project appear to think so too... see below.
Your quotes below say no such thing.

If *you* are oversharpening, that is *not* the fault of the
tool.
I explained quite clearly that I don't oversharpen. Twice. My
You explained very clearly that you were
oversharpening *in* *your*
*opinion*.

sigh I explained that I examined for halos to detect oversharpening.

You said that the way you adjusted it produced halos. Then you
blamed that mal-adjustment on GIMP.

I know part of your arsenal for usenet argument is to attack your
adversary (as adversarial is your approach to everything), but really
this is so low through repetition as to be exceeding tedious.

Then stop denying what you said, and just apologize for the
erroneous implication you intended.

Last time: I do not oversharpen; I look for halos for the avoidance of
it. Is that clear enough?

You blamed your mal-adjustment on GIMP. It was clear enough,
indeed.

So things that the development team has thought 1)
need to be
addressed, 2) some day, are in your opinion priorities now that
GIMP is several years old and the development team has gotten
down to the least important items on the priority list.

Down to the most inconvenient to implement, you mean.

It has been in /cinepaint/, a derivative of GIMP, for years.
That is open source, and obviously could have been adapted back
to the GIMP program. Insignificance is not inconvenience.

You don't understand that any better than you do quantization
distortion.

I understand quantization error more than enough for these purposes. I
also know it is not limited to sampling.

Apparently you don't. Your discussion of it here was clear
enough, just as your attempt at blaming GIMP because you can't
properly set the parameters to get correct USM.

You don't understand what happens to numbers that go through many
processing steps, losing information as they go unless they are
represented by adequately large number spaces.

Which of course has nothing to do with quantization distortion,
and also has nothing to do with 8 bit depth channels in an image
format. (But does have a lot to do with 32 bit integer
arithmetic on a typical CPU.)

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