next thread »

[GIMPel]

Hello Rolf,

thank you for that issue!
It's really great!

You asked, if this makes any sense to the viewers.
Yes it does to me.
Very clear and straight forward way of explanation.


Thanks for the F-Spot stuff. Looks quite simple to use;
this was good for me, you showed where F-Spot provides
it's add-ons and how they can be activated. I normally avoid
looking at all the menues... because I don't like to open them all
( I prefer language based attempts / scripting and so on,
and be rather a GUI-avoider) and it seems I have underestimated
the usefulness of F-Spot.

A question on the Modes for the ocatave-sharpening.
You mentioned the VALUE-mode. Why is it better?
Is it explained in the show on octave sharpening, or is it
some common knowledge on sharpening, which I missed?

Floating-Point vs. Integer: Well, I thought this is irrelevant in Python.
Seems to be important. So I may review all my Python-code
( which is not much at the moment ).

Why did you used img.width and img.height, and not drw.width and drw.height?

Thanks for the Links (Instant Python and so on).
Seems to be a good starting point to see what's important,
when starting with python.

Really great show, thank you again!

GIMPel


P.S.: The stuff on using variables instead of spagetthi code is not new to me
        (I'm programming since the eighties :-)),  but I like that you explained it,
        and how you did it. The copy&paste of already written lines of code
        is one of the biggest sources of ugly code from beginners, and you
        explained it very clear and understandable, how to do it better and why.

[rayadagio]

Yes, Rolf. Simply great.
Didactically excellent, like the legendary Python in a barrel episode!

You invented a smart way to solve the new-from-visible-problem.
I could not resist to steal the code and modify it slightly to get a surrogate function that can be inserted in every script that needs a new layer-from-visible-command:

def newfromvisible(img, name):
    new = gimp.Layer(img, name, img.width, img.height, RGB_IMAGE, 100, NORMAL_MODE)
    img.add_layer(new, -1)
    number_of_layers=len(img.layers)
    for n in xrange(number_of_layers):
        drw=img.layers[number_of_layers-n-1]
        if drw.visible==True:
            temp_layer = drw.copy(True)
            temp_layer.mode = drw.mode
            temp_layer.opacity = drw.opacity
            img.add_layer(temp_layer, -1)
            pdb.gimp_image_merge_down(img, temp_layer, 0)

I tried it with my script (updated version is already uploaded: http://forum.meetthegimp.org/index.php/topic,756.msg6118.html#msg6118) and indeed, it seems that it works. Probably the ugly insertion of a delay is no longer necessary. 

Interesting book recommendation! Thanks! Is there a substantive chapter about building GUIs?
I'm looking forward to your further impressions of this book.

And thank you for your flattery again  :-)

[mramshaw]

A question on the Modes for the ocatave-sharpening.
You mentioned the VALUE-mode. Why is it better?

VALUE mode is the equivalent of the PS mode used in the original tutorial.

Floating-Point vs. Integer: Well, I thought this is irrelevant in Python.

I have been bitten on the arse by this one since the days of Fortran. Even in the
notes Rolf read, it said that floats would be cast to ints. Even better, do what Rolf
did and make everything explicit. It's not unknown for compilers to have bugs ...

Why did you used img.width and img.height, and not drw.width and drw.height?

A drawable can also be a selection, so better to use 'img' rather than 'drw'. Not an issue
here, just a good habit to get into. Rolf copied the code from somewhere that it could have
made a big difference.

[GIMPel]

[...]
You invented a smart way to solve the new-from-visible-problem.
[...]

I was not aware that there is such a "new-from-visible-problem",
but I also was fascinated by the merge-down-function.
This was one of my notes I wrote down to a piece of paper,
while viewing the show. 

[Rolf]

I am not sure about drw or img. drw seems to be better because the layer can have a different size than the image. Is drw better? I have no clue.

Value is better, because it changes only the intensity but not the hue of the pixels. This way you avoid the colour cast while sharpening. It's common knowledge that I often forget.....

[GIMPel]

A question on the Modes for the ocatave-sharpening.
You mentioned the VALUE-mode. Why is it better?

VALUE mode is the equivalent of the PS mode used in the original tutorial.

PS-mode?   hmhhh...
... I should view that issue again...

Floating-Point vs. Integer: Well, I thought this is irrelevant in Python.

I have been bitten on the arse by this one since the days of Fortran. Even in the
notes Rolf read, it said that floats would be cast to ints. Even better, do what Rolf
did and make everything explicit. It's not unknown for compilers to have bugs ...

Well, I also have a book on Python, (python in a nutshell, rather a reference than a teaching-book),
so I should look for that topic But the mentioned tutorials seem to give a quick overview.

I thought that C is rather ugly on that, and other languages not.

In Ocaml, you can't mix values of different types. The code would not compile.
You need *. instead of * when using floats instead of ints,
and /. instead of /, and so on...

...this prevents you from a lot of runtime-trouble.

EDIT: In Perl (and some other languages too) you also have no problems with that...

Why did you used img.width and img.height, and not drw.width and drw.height?

A drawable can also be a selection, so better to use 'img' rather than 'drw'. Not an issue
here, just a good habit to get into. Rolf copied the code from somewhere that it could have
made a big difference.

hmhh, ok.

[rayadagio]

The show made me conscious that it may cause trouble if in case of a division values are set via GUI and the user is not aware of the importance of integer vs. floating point. I found helpful information about this: http://www.linuxtopia.org/online_books/programming_books/python_programming/python_ch05s06.html

According to this it is advisable to put a from __future__ import division-statement to the top of the code.


-> "Programmers should put the from __future__  statement in every Python script file, to be sure that what they are writing will work correctly. Eventually, these can be removed, but for the forseeable future, they are a necessary part of each Python script file"

[GIMPel]

The show made me conscious that it may cause trouble if in case of a division values are set via GUI and the user is not aware of the importance of integer vs. floating point. I found helpful information about this: http://www.linuxtopia.org/online_books/programming_books/python_programming/python_ch05s06.html

-> "Programmers should put the from __future__  statement in every Python script file, to be sure that what they are writing will work correctly. Eventually, these can be removed, but for the forseeable future, they are a necessary part of each Python script file"

They say: "Starting with Python 2.2, a new division operator was added to clarify what was expectred. The ordinary / operator will, in the future, return floating-point results. A special division operator, //, will return rounded-down results. Generally, the new / operator is what most mathematical processing will use."

I have python 2.6.2, and I assume we all have version > 2.2.

So this is at least a problem in the decline....


EDIT: "By version 3.0, this import statement will no longer be necessary, and these will have to be removed from the few modules that used them."

EDIT2: oh, it seems, that even in 2.6.2 the import-stuff is necessary.
I may have understood the text the other way around...
..so we will need that until 3.0 :-(

[rayadagio]

So this is at least a problem in the decline....

Apparently not. My Python 2.6.4 says 3/2=1.
What is your result?

[mramshaw]

I am not sure about drw or img. drw seems to be better because the layer can have a different size than the image. Is drw better? I have no clue.

If you are not sure I think 'img' is the better option. I have had nothing but problems with layers
that are not the same size as the image. Sometimes you may want one or the other, and often it
will be very clear which one is to be used. But if the layer is not the same size as the image, a new
layer will probably not line up properly. If you are really not sure, add a comment to the code.

[mramshaw]

A question on the Modes for the ocatave-sharpening.
You mentioned the VALUE-mode. Why is it better?

VALUE mode is the equivalent of the PS mode used in the original tutorial.

PS-mode?   hmhhh...
... I should view that issue again...

The original PDF (I just checked it) from Varis talks about a 'luminosity' layer.

I believe this is Photoshop's equivalent of a GIMP Value layer. I don't know how common
this knowledge is, but Sharpening is often decomposed to avoid sharpening colour layers
(so LAB -> L A and B -> and then the L layer is sharpened, YCbCr -> Y Cb Cr with the
Y layer sharpened, and so on). Chrominance is often another type of Noise, why sharpen it?

[monoceros84]

PS-mode?   hmhhh...
... I should view that issue again...

The original PDF (I just checked it) from Varis talks about a 'luminosity' layer.

I believe this is Photoshop's equivalent of a GIMP Value layer.

I guess he talked about Photoshop - or better a layer mode of Photoshop. That's what PS-mode means.

Photoshop's luminosity is not the same than Gimp's value. But it works similar - Gimp's value mode is the most suitable for this issue at the moment.

And as Rolf said: it's a matter of preventing coloured halos. You often see them by sharpening with a big radius.

[GIMPel]

So this is at least a problem in the decline....

Apparently not. My Python 2.6.4 says 3/2=1.
What is your result?

the same... that's, what I mentioned in my 2nd Edit of my post...
after I tried it out, I saw that I misinterpreted the text abot that
problem...

...but with Python 3.0 the problem will be solved/fixed,
but that sems to be far away in the future...

[GIMPel]

[...]
I believe this is Photoshop's equivalent of a GIMP Value layer. I don't know how common
this knowledge is, but Sharpening is often decomposed to avoid sharpening colour layers
(so LAB -> L A and B -> and then the L layer is sharpened, YCbCr -> Y Cb Cr with the
Y layer sharpened, and so on). Chrominance is often another type of Noise, why sharpen it?

It looks like there is a field where I have to get more knowledge...
...any good books on such color-components stuff?
Or tutorials?

[littletank]

@ Rayadagio: I have just tried your modified script and it does not work well at all. It is very slow compared with the previous version.