Neue Testversion 17.90b14

[Martin Huber]

Habe gerade versucht eine 16. Dialoganordnung zu speichern. Ist bei 15 Schluß.
Den die 16. wurde von PL nicht mehr gespeichert.

Es sollten eigentlich genau 16 sein. Ich werde das ändern.

Speichern kannst du prinzipiell schon mehr, aber es werden immer nur 16 ins Menü eingetragen, da es sonst recht unübersichtlich wird.

Mit den Kontrastfarben bei den Pinselwerkzeugen (die Kanalbuttons) stimmt auch was nicht.

Ja, unter Windows gibt es da ein Problem. Wir werden das reparieren.

Habe bemerkt das Objekte auf dem Hilfsgitter besser einrasten, wenn es eingeblendet ist.
Hatte eben leichte Probleme beim "fangen" am Hilfsgitter, als es unsichtbar aber aktiv war. Nach dem sichtbar machen des Rasters war das Verhalten ok.

Das kann ich bei mir nicht reproduzieren. Ist das bei dir nachvollziehbar? Wenn ja: mit welchem Werkzeug bzw. was machst du, damit das Problem sichtbar wird?

Martin

[Martin Huber]

I made a quick video demonstrating the display corruption that happens when I use the rotate view tool. This type of corruption also occurs in other instances, for example when I work in layer masks.

I can't reproduce this problem. A video is quite often not useful for me. Instead I prefer a sample document and a description, what to do to reproduce the problem.

*edit* Here's one with the layer mask display corruption:

I could reproduce this one, and this should work in the next version.

Martin

[Martin Huber]

Perhaps not a bug, but still something that breaks the non-destructive workflow:

When I create a virtual layer from a layer with a effect applied to it, like motion blur, the virtual layer, when rotated, changes its appearance completely - I would expect the virtual layer to remain identical looking to the original, but it seems the layer effect is not locked in visual appearance.

It would be extremely helpful if we could rotate, skew, etc. the virtual layer without breaking the visual appearance.

I mean, sometimes the current behaviour is actually really helpful, for example when working with a clouds live effect that recalculates in a virtual layer. But sometimes we want that effect to be fixed, and it should not be recalculated.

The solution I propose it to add an option to "FIX" the effect in the virtual layer, and it remains visually identical to the original.

That's not the way adjustment layers work.

In order to get your preferred behavior, the adjustment would have to be an layer style instead of an adjustment layer. Unfortunately adjustments can't be used as layer style at the moment.

Martin

[ellhel]

Das kann ich bei mir nicht reproduzieren. Ist das bei dir nachvollziehbar? Wenn ja: mit welchem Werkzeug bzw. was machst du, damit das Problem sichtbar wird?

Martin

Also bei mir scheint auch alles zu klappen. Vielleicht hatte ich bei eingeblendeten Hilfsgitter auch einfach nur genauer "losgelassen".
Dazu dann gleich noch eine Frage. Was passiert, wenn sich mehrere Einrastpunkte im Fangradius befinden. Angenommen PL findet in der unmittelbaren Nähe einen Hilfsgitterschnittpunkts ein normale Hilflinie und automatische Hilfslinien.
Wo liegt dann die Prorität. Wird das Hilfsgitter dann bevorzugt behandelt etc..
Hier meine Einstellungen:

Grüße
Helmut

[Martin Huber]

Was passiert, wenn sich mehrere Einrastpunkte im Fangradius befinden. Angenommen PL findet in der unmittelbaren Nähe einen Hilfsgitterschnittpunkts ein normale Hilflinie und automatische Hilfslinien.
Wo liegt dann die Prorität. Wird das Hilfsgitter dann bevorzugt behandelt etc..

Der mit der geringsten Entfernung gewinnt, wobei bei Hilfslinien (egal ob automatisch) natürlich nur die berücksichtigt werden, die sich innerhalb des Fangradius befinden.

Martin

[ellhel]

Danke

[Herbert123]

I made a quick video demonstrating the display corruption that happens when I use the rotate view tool. This type of corruption also occurs in other instances, for example when I work in layer masks.

I can't reproduce this problem. A video is quite often not useful for me. Instead I prefer a sample document and a description, what to do to reproduce the problem.

Martin

Hi Martin,

Here is the original file that causes the display problem while rotating the view.

[bkh]

It would be extremely helpful if we could rotate, skew, etc. the virtual layer without breaking the visual appearance.

That's not the way adjustment layers work.

In any case, this results in a problem when rotating the canvas (using the new rotate tool) because the direction of the motion blur doesn't change then, either.

Cheers

Burkhard.

[Herbert123]

Perhaps not a bug, but still something that breaks the non-destructive workflow:

When I create a virtual layer from a layer with a effect applied to it, like motion blur, the virtual layer, when rotated, changes its appearance completely - I would expect the virtual layer to remain identical looking to the original, but it seems the layer effect is not locked in visual appearance.

It would be extremely helpful if we could rotate, skew, etc. the virtual layer without breaking the visual appearance.

I mean, sometimes the current behaviour is actually really helpful, for example when working with a clouds live effect that recalculates in a virtual layer. But sometimes we want that effect to be fixed, and it should not be recalculated.

The solution I propose it to add an option to "FIX" the effect in the virtual layer, and it remains visually identical to the original.

That's not the way adjustment layers work.

In order to get your preferred behavior, the adjustment would have to be an layer style instead of an adjustment layer. Unfortunately adjustments can't be used as layer style at the moment.

Martin

It would be a choice between the two, which would be great to control the effect. For example, in Photoshop rotating a smart object with a smart object inside that has a live effect applied to it, the effect itself does not change when you rotate the "top-most" smart object.

I realize smart objects are different compared to virtual layers - but it would be extremely useful to be able to choose between a fixed and a live behaviour.

At the moment we cannot use adjustments as layer styles? Perhaps in the future? nudge nudge, wink wink?

[Herbert123]

It would be extremely helpful if we could rotate, skew, etc. the virtual layer without breaking the visual appearance.

That's not the way adjustment layers work.

In any case, this results in a problem when rotating the canvas (using the new rotate tool) because the direction of the motion blur doesn't change then, either.

Cheers

Burkhard.

I never noticed this before - but I really think this is odd behaviour. Rotating the view/canvas should not change the visual appearance of the content in any way, in my opinion. This is the first image editor I have come across that breaks that fundamental rule. Again, I agree with you that it could come in handy in certain circumstances (as in rotating a photo, and the motion blur remains the same), but traditionally rotating the view should in principle not have any impact visually. It's just very strange that things visually change in Photoline when we rotate the view - just imagine having a drawing on paper, and when you rotate the paper you drawing changes magically!

Suppose an artist/designer used motion blur to create a certain effect in a layer (a space ship or car zipping past from left to right, for example, with motion blur applied to it). Then the designer/artist uses the rotate view tool to draw more comfortably from another angle. Result: the effect changes completely! It will look incorrect from the designer's point of view. That's just odd and unexpected. It should stay fixed in appearance.

That is also why I mentioned this issue with adjustment layers contained in virtual layers. It forces the designer to fix the layers first before any rotation can be performed, breaking the non-destructive workflow. With virtual layers a choice would be preferable: either fixed or "live". Sometimes we want the adjustment layers contained in the virtual layer to update, and sometimes we do not. It depends.

However, I think rotating the canvas with the view rotation tool should definitely NOT change the visual appearance - at least, not by default. A choice could be given, though, to change this default to the one that is used now. The current rotate view effect on adjustment layers is very, very strange, and completely out of line with any other image editor/paint application.

[bkh]

I never noticed this before - but I really think this is odd behaviour. Rotating the view/canvas should not change the visual appearance of the content in any way, in my opinion. This is the first image editor I have come across that breaks that fundamental rule.

And I suppose that this isn't a design choice but an oversight and needs to be fixed before the "Rotate view" feature can be released.

What's maybe worse: when images are saved, the final computations take place unrotated, so that what you save will be different from what you last saw.

This also affects the new EXIF rotation (which is a feature I have been waiting for for quite some time): if you open an image with EXIF rotation, it will be rotated automatically (without the user noticing the fact), and applying motion blur (or another adjustment which involves a direction, such as "Relief", "Horizontal Edge", …) will result in a saved file which is different from what the user saw on the screen. Otoh, layer effects (which rotate with the view) behave a bit unexpectedly when you are not aware of the fact that the image is rotated.

Btw. I noticed that the EXIF rotation is not applied when one uses "Reload document".

Cheers

Burkhard.

[bkh]

There's also a bug in the "save pld along with another format" option:

Create a new picture, save it as "test.jpg". The files "test.jpg" and "test.pld" will be created.

Now save the file as "test.png". You will be asked if you want to overwrite "test.pld". If you answer "yes", the file "test.pld" will be deleted but no new file "test.pld" will be created. Even if "test.png" is modified and re-saved, there will be no new file "test.pld" (and no warning about features that cannot be saved, either). If you quit, restart PL, open "test.jpg" or "test.png", make changes and re-save, still no "test.pld" will be created (no warning, either).

Cheers

Burkhard.

[Herbert123]

I never noticed this before - but I really think this is odd behaviour. Rotating the view/canvas should not change the visual appearance of the content in any way, in my opinion. This is the first image editor I have come across that breaks that fundamental rule.

And I suppose that this isn't a design choice but an oversight and needs to be fixed before the "Rotate view" feature can be released.

What's maybe worse: when images are saved, the final computations take place unrotated, so that what you save will be different from what you last saw.

This also affects the new EXIF rotation (which is a feature I have been waiting for for quite some time): if you open an image with EXIF rotation, it will be rotated automatically (without the user noticing the fact), and applying motion blur (or another adjustment which involves a direction, such as "Relief", "Horizontal Edge", …) will result in a saved file which is different from what the user saw on the screen. Otoh, layer effects (which rotate with the view) behave a bit unexpectedly when you are not aware of the fact that the image is rotated.

Btw. I noticed that the EXIF rotation is not applied when one uses "Reload document".

Cheers

Burkhard.

Yes, I also noticed that when one my photos is opened in portrait mode, and I apply a filter like motion blur the filter preview in motion blur shows the unrotated image, and the applied motion blur is applied to different axes in the preview and the main screen. I agree that the automatic view rotation can be handy, but I did not notice at first it rotated the screen view, rather than a "real" rotation. This may be confusing.

[Martin Huber]

There's also a bug in the "save pld along with another format" option:

Create a new picture, save it as "test.jpg". The files "test.jpg" and "test.pld" will be created.

Now save the file as "test.png". You will be asked if you want to overwrite "test.pld". If you answer "yes", the file "test.pld" will be deleted but no new file "test.pld" will be created. Even if "test.png" is modified and re-saved, there will be no new file "test.pld" (and no warning about features that cannot be saved, either). If you quit, restart PL, open "test.jpg" or "test.png", make changes and re-save, still no "test.pld" will be created (no warning, either).

If all properties of the document can be saved with the original file format, no PLD file will be created and the old one will be removed. Did your document contain properties, that were lost by not saving a PLD file? If so, a sample document will be helpful.

Martin

[Martin Huber]

I never noticed this before - but I really think this is odd behaviour. Rotating the view/canvas should not change the visual appearance of the content in any way, in my opinion. This is the first image editor I have come across that breaks that fundamental rule.

And I suppose that this isn't a design choice but an oversight and needs to be fixed before the "Rotate view" feature can be released.

Yes, it's a quite fatal oversight, which makes the current implementation of "Rotate view" obsolete. So "Rotate View" will be removed and won't reappear in the near future.

Martin