GIMP

Me wrote:
Alan Browne wrote:
Me wrote:

Agreed.

Hardly. See my reply to Floyd.

Where you sarcastically denounce his photos as "snapshots" whilst
providing anecdotes to support your own brilliance?
No thanks.

Whatever excuse works for you.


--
-- 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:
I just downloaded a recent v. of GIMP for iMac. Runs under X11.

As I wrote earlier it does not support 16 bit/color very well. In fact
on loading a scan from yesterday (TIF) it immediately declared
incompetence and converted to 8 bit/color on loading.

For light editing this is not a huge deal, I admit, but it does make
changing contrast/bright/colors, etc. a lossy deal.
When done correctly, with the RAW converter (at 12 or
14 bit
depth) during the conversion process, it makes virtually no
difference for editing photographs.

Of course it does in any image that gets a lot of color, tone, contrast,
brightness, etc. adjustments in edit before final rendering as
quantization errors accumulate rapidly with 8 bit/color depth. This is
so basic.

Quantization errors? Ahem, quantization distortion is added in
the camera by the ADC, not by later editing.

You're right about "done correctly" and that is in doing it at 16
b/color before rendering to JPG.

This is so basic... and that is not correct. Just for
starters, why would you necessarily render it to JPEG?
Regardless, it is best done by the RAW converter, regardless of
whether the results are saved in 16 or 8 bit depth.


The USM is ________HORRIBLE________
Actually, it's great.

No. In PS CS3, a very light touch USM on an area of fine detail worked
fine. Identical settings (emphasis is on _light_) in gimp on the same
image created halos as well as deepened blacks with blocking up in
shadow areas. This likely includes further artifacts from the 8b/color
processing whereas in CS3 it is done at 16b/color.

Plain horrible.

You *do* have to learn how to adjust it correctly. If it
creates halos, back it off!

The problem is that you expect "identical settings" to result in
identical output. Obviously that is not correct.

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.

Imaginary? A 4000 dpi Nikon 9000ED scan of a 6x6 (56mm x 56mm to be
precise) slide is actually 8818 x 8818 pixels for about 77 Mpix. I did
a half dozen of these yesterday alone ... these can easily print to 30 x
30 inches with only the lightest touch of USM.

And of course, CS3 does this with all of the image on the screen
previewed... as one does USM at at least a 100% view to see the effect
and to make sure oversharpenning does not occur, the entire image is not
previewed, but it's a lot more than 200x200 pixels or so...

I suppose on your snapshots, Gimp USM is likely fine, but on 8800x8800
pixel posters with area selections for different levels of sharpening,
tedious Gimp USM does not even begin to cover the problem.

It would do wonders if you would take the time to learn how to
use the tools at hand.

b) and then the results of the USM are just plain terrible compared to
those in photoshop.
See above, about adjusting it correctly. That does
help
greatly.

See above. I use USM a lot, in selected areas and I use it as lightly

And you refuse to learn how to use GIMP.

as possible by examining its effects throughout contrast areas in the
whole image. Gimp USM is not only a poor tool for this ... but it does
not do what it says it will do.

It does.

It did, BTW, a reasonable job reading a DNG file and a Minolta raw file
(Maxxum 7D) but converted both to 8 bits on load, of course.

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.

Geez. I've used Gimp many times over the years and it has improved in
some areas; in the meantime PS Elements (!) and of course CS3 was always
ahead at all times, including now.

Really: Gimp is not enough despite being free.

It never will be if you continue to refuse to learn how it
works.

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

Alan Browne wrote:
Me wrote:
Alan Browne wrote:
Me wrote:

Agreed.

Hardly. See my reply to Floyd.

Where you sarcastically denounce his photos as
"snapshots" whilst providing anecdotes to support your
own brilliance?
No thanks.

Whatever excuse works for you.

So once again you resort to trivially invalid "logic" because
you simply cannot support your biases with valid arguments.

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

Floyd L. Davidson wrote:
Alan Browne wrote:
Floyd L. Davidson wrote:
Alan Browne wrote:
I just downloaded a recent v. of GIMP for iMac. Runs under X11.

As I wrote earlier it does not support 16 bit/color very well. In fact
on loading a scan from yesterday (TIF) it immediately declared
incompetence and converted to 8 bit/color on loading.

For light editing this is not a huge deal, I admit, but it does make
changing contrast/bright/colors, etc. a lossy deal.
When done correctly, with the RAW converter (at 12 or
14 bit
depth) during the conversion process, it makes virtually no
difference for editing photographs.
Of course it does in any image that gets a lot of color, tone, contrast,
brightness, etc. adjustments in edit before final rendering as
quantization errors accumulate rapidly with 8 bit/color depth. This is
so basic.

Quantization errors? Ahem, quantization distortion is added in
the camera by the ADC, not by later editing.

Quantization error occurs wherever errors creep into the data due to
operations. It's more recognized in sampling (ADC) as it often a noise
source or source of other signal artifacts; but any time data is
truncated or rounded there is a quantization error.

The weight of an error of 1/256 is much more important than an error of
1/65536. Even if you discount a few bits for less fine ADC's and noise,
let's say you're at 12 bits, well 1/4096 is still much finer than 1/256.

(My scanner is 16 b/c so I throw a generous 2.5 bits to noise)

After many manipulations of the image, the 8b version has had
accumulated errors in its lower bits (or said another way, failed to
accumulate fine adjustments). It's all about resolution and loss of
information over many manipulations of the data. Clearly 16 b/c is
better for many numerical operations on data than 8 bits...

You're right about "done correctly" and that is in doing it at 16
b/color before rendering to JPG.

This is so basic... and that is not correct. Just for
starters, why would you necessarily render it to JPEG?

For display and for submission to some print services that don't take
anything else. I do everything in 16 bit (including sharpenning) before
converting the in-memory v. to 8 bit/color for saving in JPG. (The
master is always saved as TIF if from a scan, of course to 16b/c).

Regardless, it is best done by the RAW converter, regardless of
whether the results are saved in 16 or 8 bit depth.

But, what is needed in memory for editing is 16 b/c.

The USM is ________HORRIBLE________
Actually, it's great.
No. In PS CS3, a very light touch USM on an area of fine detail worked
fine. Identical settings (emphasis is on _light_) in gimp on the same
image created halos as well as deepened blacks with blocking up in
shadow areas. This likely includes further artifacts from the 8b/color
processing whereas in CS3 it is done at 16b/color.

Plain horrible.

You *do* have to learn how to adjust it correctly. If it
creates halos, back it off!

Been there many thousand times. I mention halos as it is one of the
signs of oversharpening that I look for... and why the little Gimp
window is so pathetically useless on large images.


The problem is that you expect "identical settings" to result in
identical output. Obviously that is not correct.

I did consider that, but as the range of settings is the same I have to
assume they use the same parameters and process. A pixel radius can
only be a pixel radius. A level threshold can only be a level threshold
(although perhaps finer at 16 bit than 8 ... ah, you see what I mean!).


And of course, CS3 does this with all of the image on the screen
previewed... as one does USM at at least a 100% view to see the effect
and to make sure oversharpenning does not occur, the entire image is not
previewed, but it's a lot more than 200x200 pixels or so...

I suppose on your snapshots, Gimp USM is likely fine, but on 8800x8800
pixel posters with area selections for different levels of sharpening,
tedious Gimp USM does not even begin to cover the problem.

It would do wonders if you would take the time to learn how to
use the tools at hand.

Not only learned them (esp. sharpening and USM) when I got my first film
scanner, about 10 years ago) but refined the technique. Not saying I
don't have anything to learn, but using USM is pretty old hat. I've
used USM on all images. On my 2 prior film scanners I've scanned nearly
10,000 slided and negatives.

(But kudos on attacking me rather than the 8b/c USM (etc.) of Gimp.
Looks good in a usenet post, but really proved the point: Gimp is the
skinny kid who wants to lift weights; Photoshop lifts weights).

b) and then the results of the USM are just plain terrible compared to
those in photoshop.
See above, about adjusting it correctly. That does
help
greatly.
See above. I use USM a lot, in selected areas and I use it as lightly

And you refuse to learn how to use GIMP.

No. At approximately annual intervals I pull down the latest Gimp in
whatever OS I happen to be running and I perform a few very simple
tasks. This always begins with a TIF load. And to date (except one
version for Linux that I saw a few years ago) I always get a message
saying that it is converting the image to 8 bit/col.

Photoshop loads it as 16 b/c and you work it at 16 b/c in memory. Even
the lighter shade of photoshop (Elements) does most things at 16 b/c.

Since in an earlier post I declared that Gimp does too much at 8 bit I
decided (regretfully in retrospect) to verify that ... after all, maybe
there were improvements. So I DL'd Gimp for Mac OS X and tried it out
on scans I did yesterday (Yes, those "imaginary" 77 Mpix scans).

One of the images had an area of detail ideal for verifying the USM, an
area of white/grey/dark rocks with thin and thick bands of contrast.
Try as I might, I could not get a result that resembled the Photoshop
version. First with the same settings (blocking up, halos, contrast
exagerated) and then with lighter sharpening weight and reduced
radius... Detail was obfuscated, not enhanced. It was, at best, clunky.

As to "performing" simple tasks, it is more direct and clear in
photoshop than in gimp. Yes, it can be learned, but I'd rather acheive
x work in the minimum number of steps and time.

as possible by examining its effects throughout contrast areas in the
whole image. Gimp USM is not only a poor tool for this ... but it does
not do what it says it will do.

It does.

BZZZT. It can't. 8 b/c (1/256) is simply not as fine a level of detail
for image work as 16 (1/65536). That's just very simple integer math
doing its thing over and over, accumulating fine or coarse changes.
Stick with coarse and try to have a nice life.


It did, BTW, a reasonable job reading a DNG file and a Minolta raw file
(Maxxum 7D) but converted both to 8 bits on load, of course.

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.
Geez. I've used Gimp many times over the years and it has improved in
some areas; in the meantime PS Elements (!) and of course CS3 was always
ahead at all times, including now.

Really: Gimp is not enough despite being free.

It never will be if you continue to refuse to learn how it
works.

See above. There is no mystery to gimp. It has a clunky user interface
and works at 8 b/c v. 16 b/c for even the "amateur" version of PS. A
basic function like USM produces mediocre results v. photoshop.

To its credit, Gimp reads both DNG and camera raw files quite well, so
it is trying to keep up; but again, the editable in-memory Gimp data is
8 b/c, not 16 ( 1/256 v 1/65536).

Keep trying to justify it. I won't. A few years ago I hoped to avoid
the more expensive CS3 v. of photoshop through Gimp but soon found out
it was free ... but no bargain.

And that is my word to the OP: Gimp is free, but no bargain.

--
-- 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:
So once again you resort to trivially invalid "logic" because
you simply cannot support your biases with valid arguments.

In essence your logic is that the loss of fine detail in an image by
processing it through many steps at 8 b/c instead of 16 b/c is justified
by Gimp being free and Adobe Elements costing about $100.

Your logic is perfectly valid for a skinflint who doesn't care about
image quality. I can't argue with that.

--
-- 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:
When done correctly, with the RAW converter (at 12 or 14 bit
depth) during the conversion process, it makes virtually no
difference for editing photographs.
Of course it does in any image that gets a lot of color, tone, contrast,
brightness, etc. adjustments in edit before final rendering as
quantization errors accumulate rapidly with 8 bit/color depth. This is
so basic.
Quantization errors? Ahem, quantization distortion is
added in the camera by the ADC, not by later editing.

Quantization error occurs wherever errors creep into the data due to
operations. It's more recognized in sampling (ADC) as it often a noise
source or source of other signal artifacts; but any time data is
truncated or rounded there is a quantization error.

Go back to school.

[Large snip of equally clueless mumbling.]

The USM is ________HORRIBLE________
Actually, it's great.
No. In PS CS3, a very light touch USM on an area of fine detail worked
fine. Identical settings (emphasis is on _light_) in gimp on the same
image created halos as well as deepened blacks with blocking up in
shadow areas. This likely includes further artifacts from the 8b/color
processing whereas in CS3 it is done at 16b/color.

Plain horrible.
You *do* have to learn how to adjust it correctly. If
it
creates halos, back it off!

Been there many thousand times. I mention halos as it is one of the
signs of oversharpening that I look for... and why the little Gimp
window is so pathetically useless on large images.

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

The problem is that you expect "identical settings" to
result in
identical output. Obviously that is not correct.

I did consider that, but as the range of settings is the same I have to
assume they use the same parameters and process. A pixel radius can
only be a pixel radius. A level threshold can only be a level threshold
(although perhaps finer at 16 bit than 8 ... ah, you see what I mean!).

No, obviously you don't have a clue about what I mean or about
USM, either how it works or how to use it.

Not only learned them (esp. sharpening and USM) when I got my first film
scanner, about 10 years ago) but refined the technique. Not saying I
don't have anything to learn, but using USM is pretty old hat. I've
used USM on all images. On my 2 prior film scanners I've scanned nearly
10,000 slided and negatives.

Astounding.

(But kudos on attacking me rather than the 8b/c USM (etc.) of Gimp.

There is nothing wrong with the USM in GIMP. And whether it is
8 bit or 16 bit depth is totally irrelevant to USM.

The problem *is* you.

Why would I want to "attack" GIMP?

Try as I might, I could not get a result that resembled the Photoshop
version. First with the same settings (blocking up, halos, contrast
exagerated) and then with lighter sharpening weight and reduced
radius... Detail was obfuscated, not enhanced. It was, at best, clunky.

As to "performing" simple tasks, it is more direct and clear in
photoshop than in gimp. Yes, it can be learned, but I'd rather acheive
x work in the minimum number of steps and time.

See, it *is* you!

as possible by examining its effects throughout contrast areas in the
whole image. Gimp USM is not only a poor tool for this ... but it does
not do what it says it will do.
It does.

BZZZT. It can't. 8 b/c (1/256) is simply not as fine a level of detail
for image work as 16 (1/65536). That's just very simple integer math
doing its thing over and over, accumulating fine or coarse changes.

You clearly haven't got a clue about what actual differences
there are in using 8 bit or 16 bit. Sort of like claiming it is
quantization error... Nice big words that few people who read
this will actually have enough understanding of to know what
makes it so funny to those who do, but still hilarious none the
less.

Look up posterization. And gradients... and find out what
happens if you expand or compress the tonal range of a gradient.

Stick with coarse and try to have a nice life.

BTW, you can easily verify that too, with PhotoShop. Just put
it into 8 bit mode...

And that is my word to the OP: Gimp is free, but no bargain.

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

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

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.

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

On Mon, 01 Sep 2008 18:03:43 -0400, Alan Browne
wrote:

Floyd L. Davidson wrote:
So once again you resort to trivially invalid "logic" because
you simply cannot support your biases with valid arguments.

In essence your logic is that the loss of fine detail in an image by
processing it through many steps at 8 b/c instead of 16 b/c is justified
by Gimp being free and Adobe Elements costing about $100.

GIMP will soon (for certain values of "soon") support 32 bit
floating-point color, and will still be free.

Refs:
http://gimp.org/release-notes/gimp-2.5.html
http://gegl.org/

John A. wrote:
On Mon, 01 Sep 2008 18:03:43 -0400, Alan Browne
wrote:

Floyd L. Davidson wrote:
So once again you resort to trivially invalid "logic" because
you simply cannot support your biases with valid arguments.
In essence your logic is that the loss of fine detail in an image by
processing it through many steps at 8 b/c instead of 16 b/c is justified
by Gimp being free and Adobe Elements costing about $100.

GIMP will soon (for certain values of "soon") support 32 bit
floating-point color, and will still be free.

Thanks.

Funny. I heard that a few years ago...

I hope it's true, of course if only to see Floyd either:

-pushing it for the boon to mankind that it will be

-telling everyone not to use it as 16 b/c is not necessary...

And if 16 b/c is not necessary, then 23 bit/color is REALLY not
necessary. (assuming a 24 bit mantissa...)

But it could also take me off the CS4 path...

--
-- 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:
So once again you resort to trivially invalid "logic" because
you simply cannot support your biases with valid arguments.

In essence your logic is that the loss of fine detail in an image by
processing it through many steps at 8 b/c instead of 16 b/c is justified
by Gimp being free and Adobe Elements costing about $100.

You misunderstandings have nothing to do with my logic.

Your logic is perfectly valid for a skinflint who doesn't care about
image quality. I can't argue with that.

But since I'm usually considered a perfectionist about image
quality (most folks think to a fault), that sort of
summarization on your part is once again why your
misunderstanding is the reason you can't argue that or any other
point.

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