Neue Testversion 19.40b12

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
User avatar
Martin Stricker
Mitglied
Posts: 867
Joined: Tue 14 Oct 2003 08:19
Location: BW

Re: Neue Testversion 19.40b12 Darstellung Vektorlasso

Post by Martin Stricker »

Bei verwenden des Vektorlassos bei Zoomstufen ab 200% ist die Darstellung pixelig und das Lasso wird immer als geschlossen dargestellt. Dadurch ist exaktes Zeichnen nicht mehr möglich. Das war bei vorherigen Versionen nicht der Fall. Ich denke das ist ein Bug.

Verwendetes Betriebssystem MacOs 10.9.5

Martin
bkh
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 19.40b12 Darstellung Vektorlasso

Post by bkh »

Martin Stricker wrote:Bei verwenden des Vektorlassos bei Zoomstufen ab 200% ist die Darstellung pixelig und das Lasso wird immer als geschlossen dargestellt. Dadurch ist exaktes Zeichnen nicht mehr möglich. Das war bei vorherigen Versionen nicht der Fall. Ich denke das ist ein Bug.
Ist unter OS X 10.11.2 auch so, ebenfalls beim Kreislasso. Wenn man das Lasso in eine Vektorebene wandelt, ist es wieder glatt. Mir gefällt das alte Verhalten in der PL 19.03 auch besser.

L.G.

Burkhard.
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 19.40b12

Post by Herbert123 »

small workflow bug:

When a bitmap layer is aligned/snapped to the pixel grid (layer properties-->Alignment), and either one or both of the positional values are decimal (non integer), and a rectangular lasso is created and the layer is cropped, the result of the crop is an anti-aliased version (as if pixel alignment was turned off).

One would expect the result to look the same as when the positional values are both set to non-decimal values.

I understand why it happens, but it still is odd that the user must first manually position a layer to exact x and y values to be able to crop without anti-aliasing/recalculation even when pixel alignment is turned on for that layer (or for the entire document).

I also would like to suggest that when pixel alignment is turned on, the positioning of x and y should always occur in full pixel steps, and no longer in decimal values. The point of pixel alignment is to work with full pixel increments, I think. When pixel alignment is turned on for a layer the x and y position should change to the nearest integer value as well.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 19.40b12

Post by Herbert123 »

Scaling & rotating layer workflow improvement suggestion:

When a layer is scaled with the handles in the view, opening the layer scale (Alt S) dialog should display the same scaling values as the ones shown in the layer properties. Clicking the OK button than physically scales down the layer (the same as "fixing", but with the additional option of selecting a different interpolation method).

Currently this is not the case, and there is a disconnect between the layer properties on the one hand, and the Scale Layer and Rotate Layer dialogs on the other. I noticed that the DPI value IS automatically populated in the scale dialog based on the value set in the layer properties. It would become a more consistent and predictable user experience if scaling and rotational values are automatically applied as well. It is a tad confusing to see completely different values in those dialogs when the user already rotated and/or scaled visually.

This is also good solution for when the user wishes to scale down and/or rotate a layer physically with a different interpolation method.

Workflow steps:
1) use mouse to scale bitmap layer up or down (for example, 47%, 242.2px/176.1px as seen in the layer properties)
2) open Scale Layer (ALT S) dialog
3) Normal mode: the width and height fields are populated with the px values: 242.2px, and 176.1px respectively. Percentage mode: the fields are populated with the percentage settings 47%
4) user may decide to change interpolation mode now
5) click OK, and the layer is physically scaled down.

This would also be preferable for the "Rotate Layer" dialog. It would allow us to rotate with a specific interpolation method easily.

Also, it would be nice to have a separate "Reset" option for scaling, rotation, and skewing. Currently all three are reset simultaneously.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
bkh
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 19.40b12

Post by bkh »

Herbert123 wrote:When a layer is scaled with the handles in the view, opening the layer scale (Alt S) dialog should display the same scaling values as the ones shown in the layer properties. Clicking the OK button than physically scales down the layer (the same as "fixing", but with the additional option of selecting a different interpolation method).
So you would like "Scale Layer …" to also reset the scaling in the attributes panel to 100%? The situation is even more complicated if the (unscaled) layer is in a scaled group. Should PL still use the scaling values in the attribute panel?
Herbert123 wrote:This is also good solution for when the user wishes to scale down and/or rotate a layer physically with a different interpolation method.
Not a good solution in the "and" case. Using two separate steps results in loss of quality. I'd rather prefer a more sophisticated "Fix Layer …" dialogue which allows to select which attributes to fix and which to leave alone (so far, we only have Shift-Fix Layer to retain some attributes), and to allow to choose an interpolation method.
Herbert123 wrote:3) Normal mode: the width and height fields are populated with the px values: 242.2px, and 176.1px respectively. Percentage mode: the fields are populated with the percentage settings 47%
PL does not support layers with fractional sizes, so it would have to produce a 243 px x 177 px layer with an antialiased edge (possibly having to add an alpha channel or a layer mask), or slightly trim the image, like "Fix Layer" if there is no alpha channel. Not a big problem, but this might be a surprise to the user.

Cheers

Burkhard.
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 19.40b12

Post by Herbert123 »

I think that if the layer selected is a bitmap layer, the layer scale and rotate dialog should automatically populate the values with the ones used in the layer properties, and in those cases the images are physically adjusted.

For groups, vectors, and so on, the values can also be taken from the layer properties, since it does not matter: scaling up and down, or rotating is done non-destructive anyway.

I really think it is confusing to the user that the layer scale and rotate values fail to match the ones in the layer properties.

However, you do bring up a good point: often I wish to use a different interpolation method to convert/fix a vector layer, or a group of items, or bitmap layers. Some kind of "fix layer" dialog would be a great idea as well.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: Neue Testversion 19.40b12

Post by photoken »

Herbert123 wrote:This is also good solution for when the user wishes to scale down and/or rotate a layer physically with a different interpolation method.
As a side note/question: Which of the interpolation methods have you found works best when re-scaling:
  • Full tonal range photographs.
  • Screen captures of PL dialog boxes.
My new Thinkpad has a high-res display, and before I post sample images or screen caps of the dialog boxes here, I have to re-scale them from 144dpi to 100dpi so they display OK in the browser. I haven't gotten around to testing the various interpolation methods. Any advice?
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 19.40b12

Post by Herbert123 »

photoken wrote:
Herbert123 wrote:This is also good solution for when the user wishes to scale down and/or rotate a layer physically with a different interpolation method.
As a side note/question: Which of the interpolation methods have you found works best when re-scaling:
  • Full tonal range photographs.
  • Screen captures of PL dialog boxes.
My new Thinkpad has a high-res display, and before I post sample images or screen caps of the dialog boxes here, I have to re-scale them from 144dpi to 100dpi so they display OK in the browser. I haven't gotten around to testing the various interpolation methods. Any advice?
For down-scaling sharp edged artwork and screenshots catmul-rom works really well in my experience - it retains sharpness much better than Lanczos. Mitchell-Netravali also works well for down-scaling, but Catmull-Rom is sharper looking. Both work really well for general down-scaling.

For up-scaling I rely on Lanczos.

Check out this very informative article: https://pixinsight.com/doc/docs/Interpo ... ithms.html
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: Neue Testversion 19.40b12

Post by photoken »

Herbert123 wrote: For down-scaling sharp edged artwork and screenshots catmul-rom works really well in my experience - it retains sharpness much better than Lanczos. Mitchell-Netravali also works well for down-scaling, but Catmull-Rom is sharper looking. Both work really well for general down-scaling.

For up-scaling I rely on Lanczos.

Check out this very informative article: https://pixinsight.com/doc/docs/Interpo ... ithms.html
Thanks for the advice. I'll just keep Catmull-Rom for both when reducing images. Thanks also for that link -- I've bookmarked it for later study.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 19.40b12

Post by Herbert123 »

One minor workflow request. I noticed picas are still unsupported as a unit. Now I understand that not every unit that exists can be supported, but how about this: custom units!

It would be (sort of) revolutionary if we could set up our OWN units based on the existing ones. And the brothers never ever have to worry again about Photoline users complaining about the lack of a certain unit.

A picture is worth a thousand words:
Untitled.png
You do not have the required permissions to view the files attached to this post.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Prob: "Change" detected when no changes made

Post by photoken »

Win7 Pro x64 SP1
PL 19.40b12 x64

If an existing adjustment layer is opened and then closed without making any changes, PL flags the image as being "changed".

Steps to reproduce:
  • Create (or open) an image with an adjustment layer such as Curves or Hue Editor.
  • Open the adjustment layer's dialog.
  • Close the dialog by either hitting the "Cancel" button or the Esc key.
Result:
The image name in the Title bar gets an asterisk applied, indicating that it has been changed.

Expected result:
No indication of a "change" should appear.
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: Neue Testversion 19.40b12

Post by bkh »

Ich habe hier ein Problem mit den Farbfeldern in der aktuellen Beta, z. B. in der Werkzeugleiste oder der Farbvorschau (ganz rechts) im Farbeditor. Die Wiedergabe der Farbe im Dokument ist ok.
PL 19.40b12.png
Zum Vergleich: PL 19.03:
PL 19.03.png
Das Problem tritt bei mir nur auf, wenn ich ein LUT-Profil für den Monitor verwende und "relativ kolorimetrisch" unter Voreinstellungen -> Farbmanagement -> Standard einstelle, bei einem Matrixprofil oder mit perzeptivem Intent ist anscheinend alles ok. Das verwendete Display-Profil ist in den Screenshots. Standard-Apple-CMM und OS X 10.11.2.

Wäre nett, wenn ihr euch das mal ansehen könntet.

L.G.

Burkhard.
You do not have the required permissions to view the files attached to this post.
Martin Huber
Entwickler
Entwickler
Posts: 3942
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 19.40b12

Post by Martin Huber »

bkh wrote:Ich habe hier ein Problem mit den Farbfeldern in der aktuellen Beta, z. B. in der Werkzeugleiste oder der Farbvorschau (ganz rechts) im Farbeditor. Die Wiedergabe der Farbe im Dokument ist ok.
PL 19.40b12.png
Zum Vergleich: PL 19.03:
PL 19.03.png
Das Problem tritt bei mir nur auf, wenn ich ein LUT-Profil für den Monitor verwende und "relativ kolorimetrisch" unter Voreinstellungen -> Farbmanagement -> Standard einstelle, bei einem Matrixprofil oder mit perzeptivem Intent ist anscheinend alles ok. Das verwendete Display-Profil ist in den Screenshots. Standard-Apple-CMM und OS X 10.11.2.
Das Verhalten ist prinzipiell in der aktuellen Beta und in der 19.03 gleich. Der Hauptunterschied zwischen diesen beiden Versionen ist, dass in der 19.03 das Zielprofil das Rendering Intent vorgibt und in der Beta die Quelle. Dementsprechend bekomme ich das gleiche Verhalten in der 19.03, wenn ich unter "Voreinstellungen > Farbmanagement > Geräte" das Rendering Intent auf "Relativ farbmetrisch" stelle (weil das Gerät das Ziel ist und daher das Intent vorgibt).

Auf PhotoLine-Seite hat sich daher meiner Ansicht nach nichts geändert. Ist das Problem neu in der 10.11.2 oder kann es ein, dass es dir bisher einfach nicht aufgefallen ist?

Martin
bkh
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 19.40b12

Post by bkh »

Martin Huber wrote: Das Verhalten ist prinzipiell in der aktuellen Beta und in der 19.03 gleich. Der Hauptunterschied zwischen diesen beiden Versionen ist, dass in der 19.03 das Zielprofil das Rendering Intent vorgibt und in der Beta die Quelle. Dementsprechend bekomme ich das gleiche Verhalten in der 19.03, wenn ich unter "Voreinstellungen > Farbmanagement > Geräte" das Rendering Intent auf "Relativ farbmetrisch" stelle (weil das Gerät das Ziel ist und daher das Intent vorgibt).
Stimmt, sorry, an die Änderung in der Beta hatte ich nicht gedacht.
Martin Huber wrote: Auf PhotoLine-Seite hat sich daher meiner Ansicht nach nichts geändert. Ist das Problem neu in der 10.11.2 oder kann es ein, dass es dir bisher einfach nicht aufgefallen ist?
Durchaus möglich, dass der Effekt auch schon früher da war.

Was auffällt: wenn ich den ColorSync-Rechner unter OS X benutze, bekomme ich unabhängig von der Wiedergabeart immer ein neutrales Grau heraus (egal, ob Grau Gamma 2,2 oder sRGB-Ausgangsprofil, das sind die Standardprofile, die ich bei PL eingestellt habe), bei PL verschiebt sich der Wert stark (und eben auch nur in den Farbfeldern, nicht im Dokument).

Wenn ich bei PL die Schwarzpunktkompensation ausschalte, ist das Problem übrigens auch weg. Am Schwarzpunkt im Monitorprofil sollte es eigentlich auch nicht liegen, der ist praktisch 0.

L.G.

Burkhard.
User avatar
Gerhard Huber
Entwickler
Entwickler
Posts: 3990
Joined: Mon 18 Nov 2002 15:30
Location: Bad Gögging

Re: Neue Testversion 19.40b12

Post by Gerhard Huber »

bkh wrote:
Herbert123 wrote:Did something change in RAF (Fuji files) RAW processing? RAF files I import render with pretty bad artifacts along edges of window frames and straight edges. I can't remember that being the case last time I used FUJI files. I tested the same files in RawTherapee, and no issues there.
Looks like PL isn't performing an xtrans interpolation (instead, there are the usual choices of AHD, VNG, PPG, …). Running your first sample file through dcraw 9.26 seems to work as expected.
you are right, the xtrans interpolation was not inserted. For testing I inserted the original xtrans interpolation for Fuji RAFs, when AHD is activated. It's very very slow...