GIMP

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

Oh Man. You're really dense.

1. Regardless of the precision of an algorithm or operation, if the
resulting output is rounded, truncated or compressed to a smaller space,
then information is lost for the next operation.

2. As the simplest example today I loaded a 16 b/c TIF into Gimp. Gimp
offered to save it for me at 8 b/c. So... a lot of information lost
(whether truncated or compressed matters not).

in particular
with a 32 or 64 bit CPU.

You can do 128 bit math (integer or floating) in s/w with an 8 bit CPU
if you're patient about it. Goes to show your lack of understanding, I
guess.



Stop being silly.

I'm not. I'm dead serious. You do not understand the consequences of
many serial operations on a piece of data when it is represented at too
low a resolution.

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.

In color accuracy alone for submitting prints, it has paid handsomely.
In time not lost, many times over.

It happens that when 16 bit depth is needed, I use /cinepaint/.

Oh. Another workaround. Great. Just what people with no time on their
hands needs.

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.

I can deal with Gimp's interface as much as I could write letters on a
typewriter...

Of course that's not being fair to typewriters...

The point is not what I can do but what I can do in less time consuming
steps. I know that this is an inconvenient "non-issue" to you, but it
certainly is not to me.

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

Here's what I wrote:

"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!"

The reason 'you want to check for detail and halos' is that halos are an
indication of oversharpening. Something one would back out of by
reducing radius and/or sharpening level.

Of course trying to find that in Gimp is a tedious process...

So, now _you_ can apologize for misrepresenting what I said.

Over and out.

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

Oh Man. You're really dense.

Just can't handle a discussion without Ad Hominem, can you Alan.

Is that all you have left when someone attacks your "logic"?
Why not try truth and facts?

1. Regardless of the precision of an algorithm or operation, if the
resulting output is rounded, truncated or compressed to a smaller space,
then information is lost for the next operation.

You said for repeated operations. That is not what happens.
The repeated operations are with 32 bit arithmetic, and there
are very few times when that it actually goes back to the 8 bit
depth color. Not enough to be a significant loss, as we all
know because everyone uses JPEG, and 8 bit format.

(Not to mention that your monitor probably uses less than 8
bits!)

2. As the simplest example today I loaded a 16 b/c TIF into Gimp. Gimp
offered to save it for me at 8 b/c. So... a lot of information lost
(whether truncated or compressed matters not).

And if you *don't* make further changes, it simply isn't going
to make any difference. As I've noted, you don't normally have
to make any changes in GIMP, as opposed to the RAW converter,
where bit depth will actually affect the image. For the
abnormal case where it is needed, I use /cinepaint/.

It just isn't a big deal for photography, as opposed to what a
graphic artist needs.

in particular
with a 32 or 64 bit CPU.

You can do 128 bit math (integer or floating) in s/w with an 8 bit CPU
if you're patient about it. Goes to show your lack of understanding, I
guess.

What lack of understanding does that non-sequitur indicate? (Other than
another lapse in your logic.)

You claimed the 8 bit depth image format causes 8 bit math to be used on
a a 32 or 64 bit CPU. Who cares what an 8 bit CPU can do? What you
claimed is wrong. Your response is even sillier.

Stop being silly.

I'm not. I'm dead serious.

Okay. Dead wrong too...

You do not understand the consequences of
many serial operations on a piece of data when it is represented at too
low a resolution.

That's why *you* make arguments like the one above!

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.

In color accuracy alone for submitting prints, it has paid handsomely.
In time not lost, many times over.

So just name the printer that uses 16 bit depth, as opposed to 8
bits.

It happens that when 16 bit depth is needed, I use /cinepaint/.

Oh. Another workaround. Great. Just what people with no time on their
hands needs.

If you do graphic arts, as opposed to photography, it *does*
make a difference. Most of us do occasionally get into that.

The point is not what I can do but what I can do in less time consuming
steps. I know that this is an inconvenient "non-issue" to you, but it
certainly is not to me.

So a very complex program that you rarely use is graded as
deficent because you are more familiar with another program.

Your logic is really good Alan. Really good.

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

Alan Browne wrote:
You blamed your mal-adjustment on GIMP. It was clear
enough,
indeed.

Here's what I wrote:

"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!"

The reason 'you want to check for detail and halos' is that halos are an
indication of oversharpening. Something one would back out of by
reducing radius and/or sharpening level.

Of course trying to find that in Gimp is a tedious process...

If course it is not. Once again, when *you* oversharpen it is
not the fault of GIMP. It is very easy with GIMP to preview any
area(s) you like, and to instantly switch back and forth between
original and processed images to see the difference.

Even after you've processed the entire image it is easy to
switch back and forth at full size between the original and the
sharpened image

So, now _you_ can apologize for misrepresenting what I said.

Over and out.

I hope you do stay out.

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

Alan Browne wrote:
[]
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).

Alan, Floyd,

Could you clarify something for me please?

When you talk about 8-bit editing, you are presumably talking about
editing something like an 8-bit JPEG file, one where the gamma is
approximately 2.2.

When you talk about 16-bit editing, are you dealing with linear data, or
with gamma-corrected data?

Thanks,
David

Alan Browne wrote:

The USM is ________HORRIBLE________
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!

I don't have the latest version of The GIMP, but I doubt that it's lost
this featu Down near the bottom-right corner, there's a
four-directional arrow icon (like a + with each arm having an
outward-pointing arrowhead). Click-and-hold on that, and a thumbnail
appears there, with a box that represents your viewing area; drag that box
around the thumbnail and the image moves correspondingly within your
viewport, in real time.


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Need a new news feed? http://blinkynet.net/comp/newfeed.html

"David J Taylor" wrote:

Alan, Floyd,

Could you clarify something for me please?

When you talk about 8-bit editing, you are presumably talking about
editing something like an 8-bit JPEG file, one where the gamma is
approximately 2.2.

GIMP uses their own "XCF" format, which is an 8 bit non-linear
format that is approximately a gamma 2.5. They say the intent
is that each step from 0 to 255 has about the same change in
brightness as perceived by the human eye (on a "correctly
adjusted monitor).

When you talk about 16-bit editing, are you dealing with linear data, or
with gamma-corrected data?

It could be either, I'd suppose, depending on the program.

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

Blinky the Shark wrote:
Alan Browne wrote:

The USM is ________HORRIBLE________
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!

I don't have the latest version of The GIMP, but I doubt that it's lost
this featu Down near the bottom-right corner, there's a
four-directional arrow icon (like a + with each arm having an
outward-pointing arrowhead). Click-and-hold on that, and a thumbnail
appears there, with a box that represents your viewing area; drag that box
around the thumbnail and the image moves correspondingly within your
viewport, in real time.


I'm not Alan, but I did discover that, and I also note that you can drag
the USM dialog box larger to get a higher (but not much wider) view.
But I still find the PS method much better, esp. for web-sized images,
because the full preview gives a much better and faster overview than
panning around. My other issue is with the slider ranges in Gimp - I
generally use a radius of about 0.3 to 0.5 (or 0.5 to 2.0 for printing)
in PS, 75-200%, and ~2-7 levels depending on image content/source and
what has previously transpired. I don't tend to vary the radius and
levels much, but I do like to play about with the % to fine tune.

But in the Gimp, the range I want is not just different - it's all
squashed down at the left end of the slider and is much harder to fine
tune... It's like the difference between using a smoothly lubricated
helicoid zoom ring versus a rocker switch.. Yech. Does anyone actually
use the higher end?

Also, I find the clone tool is nowhere near as 'smooth' and does not
blend as well as it does in PS - maybe one of the (obscure) settings may
help, but I don't know which, if any.

I'd like to switch over to the Gimp, but I do find it clunky in these
and other areas - and I've always found the multiple windows annoying
when I'm doing other stuff and want to quickly flick back - which icon
was it again?

As for the 8 v 16 argument, yes, of course it is best to process the raw
file first and then leave the non-problematic stuff for later in 8-bit.
But like Alan, I do encounter 8-bit issues reasonably frequently (eg
posterising in skies when images are dropped back to b&w and then
re-adjusted). And it is an extra step to go backwards to reprocess the
raw file simply because Gimp can't do 16-bit. (having said that, I'm
still in PSCS (v8), so there are quite a few tools that don't work in
16-bit there as well..)

If these weren't issues, then why would the Gimp developers be working
on them? And if we accept that they *could* be issues, it should be
obvious that what might not be a problem for one user, may be a very big
problem for another.

Floyd L. Davidson wrote:
"David J Taylor"
wrote:

Alan, Floyd,

Could you clarify something for me please?

When you talk about 8-bit editing, you are presumably talking about
editing something like an 8-bit JPEG file, one where the gamma is
approximately 2.2.

GIMP uses their own "XCF" format, which is an 8 bit non-linear
format that is approximately a gamma 2.5. They say the intent
is that each step from 0 to 255 has about the same change in
brightness as perceived by the human eye (on a "correctly
adjusted monitor).

When you talk about 16-bit editing, are you dealing with linear
data, or with gamma-corrected data?

It could be either, I'd suppose, depending on the program.

So GIMP would convert a JPEG from its "gamma-corrected" space to its own
XCF space before processing?

Working with data which is gamma corrected does alter the appearance of
operations like addition and multiplication (compared to working in linear
space), so it may be important to know what transfer characteristic is
being assumed.

Thanks for your reply.

David

Mark Thomas wrote:
Blinky the Shark wrote:
Alan Browne wrote:

The USM is ________HORRIBLE________
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!

I don't have the latest version of The GIMP, but I doubt that it's lost
this featu Down near the bottom-right corner, there's a
four-directional arrow icon (like a + with each arm having an
outward-pointing arrowhead). Click-and-hold on that, and a thumbnail
appears there, with a box that represents your viewing area; drag that
box
around the thumbnail and the image moves correspondingly within your
viewport, in real time.


I'm not Alan, but I did discover that, and I also note that you can drag
the USM dialog box larger to get a higher (but not much wider) view. But
I still find the PS method much better, esp. for web-sized images,
because the full preview gives a much better and faster overview than
panning around. My other issue is with the slider ranges in Gimp - I
generally use a radius of about 0.3 to 0.5 (or 0.5 to 2.0 for printing)
in PS, 75-200%, and ~2-7 levels depending on image content/source and
what has previously transpired. I don't tend to vary the radius and
levels much, but I do like to play about with the % to fine tune.

But in the Gimp, the range I want is not just different - it's all
squashed down at the left end of the slider and is much harder to fine
tune... It's like the difference between using a smoothly lubricated
helicoid zoom ring versus a rocker switch.. Yech. Does anyone actually
use the higher end?

Yes I agree. It means using the scroll buttons on the slider rather
than the slider itself when making fine adjustments. When the USM
window is increased in size, then the sliders are longer - so easier to
adjust, but afaik there's no way to either make the USM window always
appear maximised, or to make USM settings "stick" between sessions.
There's always the option to report these as bugs, so that it might be
fixed (or to participate in the project further and fix it yourself).

Also, I find the clone tool is nowhere near as 'smooth' and does not
blend as well as it does in PS - maybe one of the (obscure) settings may
help, but I don't know which, if any.

There's settings to select brush shapes including "fuzzy", opacity,
applying jitter, toggling hard edge on and off etc. I don't think that
there's a lot of difference. I use a Wacom tablet for cloning. It
works fine in Gimp (or PS).

I'd like to switch over to the Gimp, but I do find it clunky in these
and other areas - and I've always found the multiple windows annoying
when I'm doing other stuff and want to quickly flick back - which icon
was it again?

As for the 8 v 16 argument, yes, of course it is best to process the raw
file first and then leave the non-problematic stuff for later in 8-bit.
But like Alan, I do encounter 8-bit issues reasonably frequently (eg
posterising in skies when images are dropped back to b&w and then
re-adjusted). And it is an extra step to go backwards to reprocess the
raw file simply because Gimp can't do 16-bit. (having said that, I'm
still in PSCS (v8), so there are quite a few tools that don't work in
16-bit there as well..)

IMHO a lot depends on the raw processor and how you use it. I tend to
use NX for everything except for major cloning and perspective
correction (done in Gimp) or lens correction (done in PTLens). I have
no need for photoshop at all, except I still use it for printing,
because I like the Gamut Warning and Soft Proof features. QImage could
possibly replace PS for that - I haven't used it for a while, IIRC it
has soft proof (so does Gimp) but not gamut warning features.


If these weren't issues, then why would the Gimp developers be working
on them? And if we accept that they *could* be issues, it should be
obvious that what might not be a problem for one user, may be a very big
problem for another.

16 bit is the big issue IMO.
But I think that programs like NX, possibly lightroom, are the future as
they are designed from ground up for digital photography. But changing
from the old paradigm of using PS (or Gimp or PSP etc) as the primary
"tool" is too much for some.