Neue Testversion 18.40b9

[Gerhard Huber]

Hallo,

es gibt wieder eine neue Testversion 18.40b9.

Windows:
http://www.pl32.com/beta/pl1840b9.zip

Mac OS X:
http://www.pl32.com/beta/plx1840b9.zip


Neues:
- Dockbare Dialoge mit einstellbarem Namen


diverse kleinere Verbesserungen und Fehlerbehebungen


Gerhard Huber [Computerinsel GmbH]
support@pl32.de - http://www.pl32.de

[ellhel]

Hallo,

das Problem mit dem Spezialkanal konntet Ihr in der kurzen Zeit anscheinend noch nicht in Angriff nehmen. Bei umschalten auf "32-bit" wandert die Maske noch weiter nach links.

Mir ist gerade aufgefallen, das die Pinselgröße "andersherum" reagiert, wenn man das Bild auf den Kopf gedreht hat (meine mit dem "Ansicht drehen" Werkzeug).
Beim ziehen nach rechts mit gedrückter Maustaste wird der Durchmesser kleiner usw.....

Super......man kann die Symbolleisten passend benennen. Sieht doch viel besser aus. Viiiielen Dank dafür..

Symbolleisten umbenannt.jpg

liebe Grüße
Helmut

[JulianZI]

Irgendwie ist das verknüpfte Kopieren nicht ideal.

Wenn man diese Option wählt, werden die aktuelle Ebene und die darunterliegenden ausgewertet, damit ist es nicht möglich einfach nur das sichtbare zu kopieren weil die Ebenen darüber ja nicht ausgewertet werden (wenn das Ziel eine tiefere Ebene ist).

Dieses Verhalten könnte eigentlich eine sehr raffinierte Verfahrensweise erlauben - nämlich man legt als Kopierziel eine Ebene ganz oben an, auf die dann kopiert wird - sinn: nur die Daten darunter sollen kopiert werden, nicht aber was man gerade kopiert hat. Das Problem ist jetzt nur, auch diese Ebene wird ausgewertet , auch wenn man den ALT+KLICK auf einer anderen Ebene ausgeführt hat.

ALT-KLICK sollte sich nicht nur die Position, sondern auch die Z-Order der Ebene, die beim Klick aktiviert war, merken. Dann wäre die Funktion stimmig und vielseitig beim Kopieren von mehreren Ebenen.

Es fehlt meiner Ansicht nach eine zusätzliche Option: "Kopieren wie sichtbar" um den Workaround mit der neuen Ebene ganz oben zu vermeiden. (Diese Vorgehensweise könnte man vielleicht im Handbuch aufnehmen)

[photoken]

Es fehlt meiner Ansicht nach eine zusätzliche Option: "Kopieren wie sichtbar" um den Workaround mit der neuen Ebene ganz oben zu vermeiden. (Diese Vorgehensweise könnte man vielleicht im Handbuch aufnehmen)

My apologies if the bing translator has caused me to misunderstand what you're trying to do:

An additional option is lacking in my opinion: "Copy as visible" to avoid the workaround with the new layer at the top. (You could record perhaps this procedure in the manual)

What I've done is to modify the provided "Create Merged Layer" action so that only the layers that I've marked are copied to a new layer:

merged layer action mods.png

[JulianZI]

My note was about the copy brush - my suggestion was the program should remember not only the position, but also the Z-order of the source layer. Right now it always copies the current layer (and optionally the deeper layers), but it is not possible to exclude the current layer from the source.

The suggested option "copy as visible" is pretty obvious, it would just do what many would expect, copy what's visible by ignoring that the source can be come from layers, too.

[Ashcraaft]

Dockbare Dialoge mit einstellbarem Namen

Was genau ist damit gemeint?

[ellhel]

Das ist auf die Symbolleisten bezogen. Du kannst ja die Symbolleisten komplett "umgestalten". So wie bei mir (siehe Bild oben). Ich habe die wirklich total geändert.
Wenn die Symbolleisten dann unter oder über den Dialogen eingefügt waren sah es "komisch" aus, da der Name der Symbolleiste nichts mehr mit dem Inhalt zu tun hatte.
Jetzt kannst Du unter "Einstellung/Bedienung/Symbolleiste" den Namen frei wählen.

Symbolleiste Namen ändern.jpg

liebe Grüße
Helmut

[photoken]

It's great that PL now offers the DCB de-mosaic algorithm for RAW images. As I understand it, there should be some options included in the PL settings to fine-tune the output:

• Number of iterations (0-5). Apparently, the default is zero while "2" is usually the optimum.
• False color correction steps (0-5).
• Refined mode On/Off. Default is "On", which is better.

[bkh]

It's great that PL now offers the DCB de-mosaic algorithm for RAW images. As I understand it, there should be some options included in the PL settings to fine-tune the output:

There are two problems here, imo.:

• too many options are very confusing for the user. For example, what's refined mode, compared with increasing the number of iterations/steps, and which gives the best results? Does increasing the values always gives better results? How do these options affect quality vs. speed?
• where to put all these options. Imo, it makes sense to have all available options in the Attributes panel (so far, dcb itself isn't accessible from there at all), so that it's possible to re-interpret the raw without having to reload the file.

Maybe one could restrict the choices to something like "dcb quick" and "dcb best" (similar to VNG linear/cubic), with suitably chosen parameters?

Cheers

Burkhard.

[photoken]

too many options are very confusing for the user.

1. The photographer who is interested/knowledgeable enough to choose a particular demosaic algorithm isn't going to be easily confused and deserves to have all the appropriate options available.
2. The "best" options will vary with the make of camera, subject matter, camera settings, etc. So experimenting will always be a part of using RAW....
3. For the users who don't want to be confused or bothered, they can always ignore everything and simply accept the defaults.

where to put all these options. Imo, it makes sense to have all available options in the Attributes panel (so far, dcb itself isn't accessible from there at all), so that it's possible to re-interpret the raw without having to reload the file.

It's an appealing thought to have the options in the Attributes panel, but whenever DCB options are changed, the RAW file must, by definition, be re-loaded. Therefore, having them in the program's Options dialog makes sense to me. I'm finding that these specific DCB options, once arrived at, won't be changed all that often -- only in extreme circumstances (images of black cats in a coal bin at midnight ) are the options likely to need adjusting.

[bkh]

1. The photographer who is interested/knowledgeable enough to choose a particular demosaic algorithm isn't going to be easily confused and deserves to have all the appropriate options available.

… if you have a reasonable description of what each option does – otherwise, leaving it to the end user to try 50 combinations of settings to find the optimal one by chance isn't going to be helpful. Leaving too many choices to the user normally is a sign that the programmer hasn't spent enough effort to select a few distinct useful ones. Btw., dcb_dcraw only seems to have two parameters, -Q and -E (so "only" 12 choices).

2. The "best" options will vary with the make of camera, subject matter, camera settings, etc. So experimenting will always be a part of using RAW....

The author claims that -Q 2 normally gives best results – and all of his examples use -Q 2 (with or without -E). Do you have examples where a setting other than -Q 2 gives a significantly better result?

It's an appealing thought to have the options in the Attributes panel, but whenever DCB options are changed, the RAW file must, by definition, be re-loaded. Therefore, having them in the program's Options dialog makes sense to me. I'm finding that these specific DCB options, once arrived at, won't be changed all that often -- only in extreme circumstances (images of black cats in a coal bin at midnight ) are the options likely to need adjusting.

It's an appealing thought to have the options in the Attributes panel, but whenever DCB options are changed, the RAW file must, by definition, be re-loaded. Therefore, having them in the program's Options dialog makes sense to me.

No, the raw data just has to be reinterpreted (just like the other algorithms which can be chosen from the Attributes panel). Having to go through the option dialogue followed by an "Open" dialogue certainly wouldn't encourage me to experiment. Being able to change the demosaicing algorithm at a later point is one of the strengths of PL as a raw developer, imo.

Cheers

Burkhard.

[OldRadioGuy]

Viveza 2 exhibits color rendering problem in PhotoLine 18.40b9

In 16-bit TIF images, the Google Nik Collection Viveza 2 plugin fails to render color correctly in PhotoLine 18.40b9.

1. Open a 16-bit color image in PhotoLine
2. Go to Filter -> Nik Collection -> Viveza 2
(Image opens in Viveza window with image magnification 1:1; rendering of that part of image shown in main window is correct, but rendering in Loupe is incorrect.)
3. Press "F" to make Viveza fullscreen
4. Select "-" magnifier tool
5. Press "-" magnifier on main Viveza window to reduce magnification
(The magnification of the image is reduced and the rendering anomaly in the loupe is transferred to the main window while color is correct in the loupe. See example below.)

Viveza Example.jpg

I tested this using the Viveza 2 standalone set up to run as an external program in PhotoLine: Filter -> External Programs -> Viveza 2, and I found the same behavior exhibited. I also tested Viveza 2 as a plugin in Zoner Photo Studio Pro 16 Editor. The result was the same anomaly exhibited in PhotoLine.

However, when I ran the plugin in Photoshop Elements 12, Viveza performed correctly.

I called Google Nik Collection technical support. The tech said they only supported Adobe and Apple host, suggesting a compatiblity problem in PhotoLine and Zoner.

Both 8-bit TIFs and JPEGs run correctly in Viveza 2 via PhotoLine, however.

Bob

[photoken]

… if you have a reasonable description of what each option does – otherwise, leaving it to the end user to try 50 combinations of settings to find the optimal one by chance isn't going to be helpful. Leaving too many choices to the user normally is a sign that the programmer hasn't spent enough effort to select a few distinct useful ones. Btw., dcb_dcraw only seems to have two parameters, -Q and -E (so "only" 12 choices).

I disagree. The minimal descriptions available on the Web of the DCB parameters is sufficient for a user to begin experimenting. Having a lot of choices is a Good Thing, since that allows accommodation for extreme images and a wide variety of cameras. Again, if a photographer wants to spend the time to find the optimum settings for his camera, those options are necessary. If the photographer doesn't want to be bothered with experimenting, then there's no confusion -- simply allow the default settings to be applied.

The author's Web page (http://www.linuxphoto.org/html/algorithms.html) lists the three parameters that I mentioned, which are also the parameters available for DCB in RawTherapee.

The author claims that -Q 2 normally gives best results – and all of his examples use -Q 2 (with or without -E). Do you have examples where a setting other than -Q 2 gives a significantly better result?

The short answer is "No", and the operative word is "significantly". The long answer is that at 100% in RawTherapee I can maybe see a very slight improvement in sharpness using 5 iterations versus 2 iterations. My LF1 is a compact camera, and even though its sensor is large for a compact camera, it's still a small sensor and I want to have as many post-processing options as I can get to extract the maximum quality out of the images.
Edit:
The default for DCB is 0, so having the option to use more iterations becomes doubly important.

No, the raw data just has to be reinterpreted (just like the other algorithms which can be chosen from the Attributes panel). Having to go through the option dialogue followed by an "Open" dialogue certainly wouldn't encourage me to experiment. Being able to change the demosaicing algorithm at a later point is one of the strengths of PL as a raw developer, imo.

Ah, now I see where that can be selected in the Attributes panel. That panel has plenty of room for the addition of three options for DCB. But, like I mentioned, once a valid set of parameters has been determined, those parameters will be applicable to just about all the images from that camera, so having the initial options globally set in the PL options dialog is good.

[bkh]

The author's Web page (http://www.linuxphoto.org/html/algorithms.html) lists the three parameters that I mentioned, which are also the parameters available for DCB in RawTherapee.

What's the third parameter then, in your opinion, besides -Q and -E? The -N option is for the denoising algorithm only.

The long answer is that at 100% in RawTherapee I can maybe see a very slight improvement in sharpness using 5 iterations versus 2 iterations.

So is 5 always sharper (and slower) than 2, then? Would it be enough to offer "dcb fast (Q=2) and dcb sharp (Q=5)? Or does 5 produce more artefacts as well, and choosing 0 to 5 means trading sharpness for artefacts (and speed)? Don't get me wrong, I'm not against options in general, but I don't like the "try them all if you want to know what they mean" attitude – I think that this will keep many people from trying – and from finding the optimal solution.

Cheers

Burkhard.

[Hoogo]

... but I don't like the "try them all if you want to know what they mean" attitude – I think that this will keep many people from trying – and from finding the optimal solution...

That reminds me a bit of Ximagic Denoiser. I really like that tool, it supports RGB/Lab/YCbCr, lots of algorithms, lots of properties to adjust. I surely love this tool, it even offers to store temporary presets so you can try and adjust and compare as much as you want. And the results are great, too.

But it takes a lot of time, and I still have no clue when denoising with DCT could have an advantage to NLM.
And even though you get an idea of the parameters after a while and you "know" how to interpret a difference picture, I often prefer my NeatImage: Let the program look for a sample, maybe give a sample by your own, then some special sliders you know what they do, and you're done.