Neue Testversion 18.40b9

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
Antworten
Benutzeravatar
Gerhard Huber
Entwickler
Entwickler
Beiträge: 4141
Registriert: Mo 18 Nov 2002 15:30
Wohnort: Bad Gögging

Neue Testversion 18.40b9

Beitrag von 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
Benutzeravatar
ellhel
Mitglied
Beiträge: 1342
Registriert: Mi 04 Jan 2012 03:03
Wohnort: Reiffelbach

Re: Neue Testversion 18.40b9

Beitrag von 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
Symbolleisten umbenannt.jpg (35.47 KiB) 1952 mal betrachtet
liebe Grüße
Helmut
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
Beiträge: 736
Registriert: Di 19 Dez 2006 19:54
Wohnort: München

Re: Neue Testversion 18.40b9

Beitrag von 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)
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Re: Neue Testversion 18.40b9

Beitrag von photoken »

JulianZI hat geschrieben: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
merged layer action mods.png (2.26 KiB) 1919 mal betrachtet
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
JulianZI
Mitglied
Beiträge: 736
Registriert: Di 19 Dez 2006 19:54
Wohnort: München

Re: Neue Testversion 18.40b9

Beitrag von 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
Beiträge: 487
Registriert: Fr 26 Nov 2010 10:39
Wohnort: Kempen
Kontaktdaten:

Re: Neue Testversion 18.40b9

Beitrag von Ashcraaft »

Gerhard Huber hat geschrieben: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)
Benutzeravatar
ellhel
Mitglied
Beiträge: 1342
Registriert: Mi 04 Jan 2012 03:03
Wohnort: Reiffelbach

Re: Neue Testversion 18.40b9

Beitrag von 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
Symbolleiste Namen ändern.jpg (22.37 KiB) 1889 mal betrachtet
liebe Grüße
Helmut
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
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Req.: Options for DCB de-mosaic algorithm

Beitrag von 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
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

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

Beitrag von bkh »

photoken hat geschrieben: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.
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

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

Beitrag von photoken »

bkh hat geschrieben: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 hat geschrieben: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
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

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

Beitrag von bkh »

photoken hat geschrieben: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 hat geschrieben: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 hat geschrieben: 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 hat geschrieben: 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.
Benutzeravatar
OldRadioGuy
Mitglied
Beiträge: 416
Registriert: Fr 24 Apr 2009 19:09
Wohnort: Austin, Texas, USA
Kontaktdaten:

Re: Neue Testversion 18.40b9

Beitrag von 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
Viveza Example.jpg (46.53 KiB) 1832 mal betrachtet
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
PhotoLine 24.xx |DxO PureRAW 3 |Various Third-Party Plugins | macOS 14.11 | Apple M2 Max | 64 GB Memory | E-M1markIII.
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

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

Beitrag von photoken »

bkh hat geschrieben: … 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 hat geschrieben: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 hat geschrieben: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
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

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

Beitrag von bkh »

photoken hat geschrieben: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 hat geschrieben: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.
Benutzeravatar
Hoogo
Betatester
Beiträge: 4020
Registriert: So 03 Jul 2005 13:35
Wohnort: Mülheim/Ruhr

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

Beitrag von Hoogo »

bkh hat geschrieben:... 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!
Antworten