Neue Testversion 18.40b9

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
User avatar
Gerhard Huber
Entwickler
Entwickler
Posts: 4028
Joined: Mon 18 Nov 2002 15:30
Location: Bad Gögging

Neue Testversion 18.40b9

Post by 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
User avatar
ellhel
Mitglied
Posts: 1338
Joined: Wed 04 Jan 2012 03:03
Location: Reiffelbach

Re: Neue Testversion 18.40b9

Post by 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.. :wink:
Symbolleisten umbenannt.jpg
liebe Grüße
Helmut
You do not have the required permissions to view the files attached to this post.
PhotoLine 21 & Betas, Win-10 Pro 64-bit, ACDSee Photo Studio Ultimate 2018, Dxo Optics Pro 9, Panasonic DMC-G6
"Der Nachteil der Intelligenz besteht darin, dass man ununterbrochen gezwungen ist, dazuzulernen."
George Bernard Shaw
JulianZI
Mitglied
Posts: 734
Joined: Tue 19 Dec 2006 19:54
Location: München

Re: Neue Testversion 18.40b9

Post by 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)
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: Neue Testversion 18.40b9

Post by photoken »

JulianZI wrote: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
You do not have the required permissions to view the files attached to this post.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
JulianZI
Mitglied
Posts: 734
Joined: Tue 19 Dec 2006 19:54
Location: München

Re: Neue Testversion 18.40b9

Post by 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
Mitglied
Posts: 484
Joined: Fri 26 Nov 2010 10:39
Location: Kempen

Re: Neue Testversion 18.40b9

Post by Ashcraaft »

Gerhard Huber wrote:Dockbare Dialoge mit einstellbarem Namen
Was genau ist damit gemeint?
Bitte besuche & teile PhotoLine auf folgenden Seiten:
PhotoLine bei Facebook | YouTube

Danke, Sascha Ballweg
(Photoline-Nutzung: Mac OS-X & Windows 10)
User avatar
ellhel
Mitglied
Posts: 1338
Joined: Wed 04 Jan 2012 03:03
Location: Reiffelbach

Re: Neue Testversion 18.40b9

Post by 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
You do not have the required permissions to view the files attached to this post.
PhotoLine 21 & Betas, Win-10 Pro 64-bit, ACDSee Photo Studio Ultimate 2018, Dxo Optics Pro 9, Panasonic DMC-G6
"Der Nachteil der Intelligenz besteht darin, dass man ununterbrochen gezwungen ist, dazuzulernen."
George Bernard Shaw
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Req.: Options for DCB de-mosaic algorithm

Post by 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.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
bkh
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Req.: Options for DCB de-mosaic algorithm

Post by bkh »

photoken wrote: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.
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: Req.: Options for DCB de-mosaic algorithm

Post by photoken »

bkh wrote: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.
bkh wrote: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 :wink: ) are the options likely to need adjusting.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
bkh
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Req.: Options for DCB de-mosaic algorithm

Post by bkh »

photoken wrote: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).
photoken wrote: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?
photoken wrote: 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 :wink: ) are the options likely to need adjusting.
photoken wrote: 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.
User avatar
OldRadioGuy
Mitglied
Posts: 412
Joined: Fri 24 Apr 2009 19:09
Location: Austin, Texas, USA

Re: Neue Testversion 18.40b9

Post by 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
You do not have the required permissions to view the files attached to this post.
PhotoLine 23.xx | DxO PhotoLab 5 | ON1 Photo RAW 2022 | Various Third-Party Plugins | macOS 11.4 | iMac (Retina 5K, 27-inch, 2017) | Intel Core i7 @ 4.2 GHZ | 32 GB 2400 MHz DDR4 | Radeon Pro 580 8192 MB | E-M1markIII, PEN-F.
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: Req.: Options for DCB de-mosaic algorithm

Post by photoken »

bkh wrote: … 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.
bkh wrote: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.
bkh wrote: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.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
bkh
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Req.: Options for DCB de-mosaic algorithm

Post by bkh »

photoken wrote: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.
photoken wrote: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.
User avatar
Hoogo
Betatester
Posts: 3927
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Req.: Options for DCB de-mosaic algorithm

Post by Hoogo »

bkh wrote:... 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.
----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!