Neue Testversion 19.40b11

[Martin Huber]

- ICC-Farbprofile: Testweise gibt die Quelle das Rendering Intent an

Was genau bedeutet das? Wann wirkt diese Funktion bzw. an welcher Stelle verhält PhotoLine sich dadurch anders?

An ICC-Farbraumkonvertierungen sind ja immer zwei Profile beteiligt: das Quellprofil und das Zielprofil. Dabei ist aber nur eine Wiedergabeart (Rendering Intent) möglich.

Bisher gab in PhotoLine das Zielprofil die Wiedergabeart an, jetzt ist es das Quellprofil. Dieses Verhalten passt auch besser zu PDF-Dateien.
PhotoLine-intern hat das überwiegend Einfluss auf "Farbprofil zuweisen". Während die hier eingestellte Wiedergabeart nur bei Seiten/Dokumenten einen Einfluss hatte (weil die ja üblicherweise das Ziel einer Farbraumtransformation sind), und bei Ebenen keine Auswirkung hatte, siehst du nun bei Ebenen direkt eine Auswirkung.
Du kannst nun also z.B. in einem RGB-Dokument ein CMYK-Bild platzieren und gezielt die Wiedergabeart für dieses eine Bild setzen. Das ging früher nicht.

Martin

[Hoogo]

There's Strg + Shift + Pageup/down to navigate in the layer list.

[Juan]

There's Strg + Shift + Pageup/down to navigate in the layer list.

As far as I know it doesn´t navigate inside a layer group.

Cheers,
Juan

[bkh]

There's Strg + Shift + Pageup/down to navigate in the layer list.

As far as I know it doesn´t navigate inside a layer group.

You can assign keys to "Enter group"/"Leave group" as well (don't know if they have keys assigned by default).

Cheers

Burkhard.

[Hoogo]

Maybe a little change for that command will do for everyone, what if it navigates in any open layer? Not sure if it would corrupt current macros.

[Juan]

There's Strg + Shift + Pageup/down to navigate in the layer list.

As far as I know it doesn´t navigate inside a layer group.

You can assign keys to "Enter group"/"Leave group" as well (don't know if they have keys assigned by default).

Cheers

Burkhard.

Thanks for the tip, but then you will end up with two commands only for layer navigation, not sure about this... not so workflow friendly. So...

Maybe a little change for that command will do for everyone, what if it navigates in any open layer? Not sure if it would corrupt current macros.

This could be the solution, if a group is open then the navigation continues to the child layers, if the group is closed then it skips the child layers.

Cheers,
Juan

[bkh]

Maybe a little change for that command will do for everyone, what if it navigates in any open layer? Not sure if it would corrupt current macros.

This could be the solution, if a group is open then the navigation continues to the child layers, if the group is closed then it skips the child layers.

Imo, this isn't a good idea because the keyboard command goes to the document window (and will even work when the layer panel is closed). What can be seen in the layer panel is just the side effect of what happens in the window which has the focus, so the layer panel should not affect how it works. Besides, this would make future macros dependent on which groups are open/closed in the layer panel (or, at least, one would have to program them very carefully to avoid this problem). The only alternative I can see is one set of commands like the present ones, and one set of commands/keys which open/close all groups along the way. (Or go back to the behaviour in 19.40b10 where one moves in the layer panel and what happens in the document window is the side effect.)

Keyboard focus should go where the user focus is, really, but computers are still too stupid to get that right.

Cheers

Burkhard.

[beiti]

PhotoLine-intern hat das überwiegend Einfluss auf "Farbprofil zuweisen". Während die hier eingestellte Wiedergabeart nur bei Seiten/Dokumenten einen Einfluss hatte (weil die ja üblicherweise das Ziel einer Farbraumtransformation sind), und bei Ebenen keine Auswirkung hatte, siehst du nun bei Ebenen direkt eine Auswirkung.

Ich hatte mich ja schon länger gefragt, wozu man bei "Farbprofil zuweisen" überhaupt einen Rendering Intent einstellen kann.

Nun habe ich es mit einem ISOcoated-CMYK-Dokument und einer sRGB-Ebene darin getestet.
Ich hätte erwartet, dass in dem Moment, wo ich einer Ebene einen Farbraum und einen Rendering Intent zuweise, der fürs Dokument eingestellte Rendering Intent "überschrieben" wird. Tatsächlich hat aber der Rendering Intent des Dokumentes weiterhin Einfluss aufs Ergebnis. Das verstehe ich nicht.

[bkh]

Nun habe ich es mit einem ISOcoated-CMYK-Dokument und einer sRGB-Ebene darin getestet.
Ich hätte erwartet, dass in dem Moment, wo ich einer Ebene einen Farbraum und einen Rendering Intent zuweise, der fürs Dokument eingestellte Rendering Intent "überschrieben" wird. Tatsächlich hat aber der Rendering Intent des Dokumentes weiterhin Einfluss aufs Ergebnis. Das verstehe ich nicht.

Wenn ich das richtig verstehe, wird die Ebene mit dem Ebenen-Intent in den Farbraum des Dokuments umgerechnet (nur so kann das Ergebnis mit den darunter liegenden Ebenen verrechnet werden). Beim Speichern spielt der Dokument-Intent keine Rolle. Bei der Ausgabe des Dokuments wird dann mit dem Dokument-Intent in den Display- oder Druckerfarbraum umgerechnet, auch bei der Wandlung nach sRGB beim Web-Export.

L.G.

Burkhard.

[photoken]

The thing is, I do not see any benefit in having to consciously activate the view when I select a layer in the layer panel

The benefit comes from telling the program what you want to work with. With the old, incorrect behaviour of the Layers panel, you cannot use the keyboard to perform any action on the layer itself that's selected because the input focus is always bizarrely on a completely different window -- the main editing window.

This old behaviour is not only inconsistent with the other lists, panels, and dialogs in PL, but also prevents future enhancements. The new, correct behaviour where the Layers panel retains the input focus will allow features like using the Esc key to toggle the visibility of the selected layer on and off, etc.

Consider the case where you have a vector object selected. If you open the Color List, you can use the arrow keys to move through the colours (and see the effect of the colour change on the object).

Why can't I have that convenience with the Layers panel?

Consider the Layers panel itself -- if you open the drop down for the blend modes, you can use the arrow keys to move through the blend modes (and see the effect of the chosen blend mode).

Why can't I have that convenience in the Layers panel itself?

And who is saying the cursor keys are generally used to select things?
...
And according to GUI standards: agreed, list views can be NAVIGATED by pressing the cursor keys.

Yes, I agree. I am talking about having the ability to use the cursor keys to navigate through the layers. It's a feature of application design that, in a list, the item that has been highlighted by navigating to it is selected.

In short, I think we should have these options:
...

That shows the inherent problems with the old, incorrect behaviour -- one would have to add more and more complex workarounds to compensate for its behaviour. My previous suggestion (using the new, correct behaviour of the Layers panel) for the arrow keys and the ">" & "<" keys is simple, direct and elegant.

Just a note for the lurkers who are probably getting very bored with this discussion about the behaviour of the Layers panel:
123 and I are having this discussion (and it's an important disciussion, IMO) because we share the same ideal of navigating through the layers and also precisely moving layer content without having to use the mouse. We are simply examining the best way to implement that.

[Herbert123]

That shows the inherent problems with the old, incorrect behaviour -- one would have to add more and more complex workarounds to compensate for its behaviour. My previous suggestion (using the new, correct behaviour of the Layers panel) for the arrow keys and the ">" & "<" keys is simple, direct and elegant.

Aside from all the noise of how a GUI standard works, let's talk about efficiency of workflow. I believe in efficiency. Less clicks and key presses to achieve a task is better in my opinion.

My point is that your method increases the number of keystrokes and/or mouse actions: we would have to activate the layers panel first to work in it, and then again activate the main view window before we could continue to work in the main view. And we already have established that the use of the mouse to activate the main view is at the very least quite awkward (with risks of losing the selection and inconvenient exact clicking on specific window areas). And what about users who do not wish to use shortcut keys at all? You force them to use the mouse to somehow activate the main window.

The current method does not require those extra steps. Only the behaviour of the previous and next layer ought to be addressed a bit to improve layer navigation. And we can already hide and show layers with the keyboard (I assigned <ctrl>-H to accomplish this). There is just no need to activate the layer panel first for additional actions - your approach will merely increase the number of clicks and key presses required to do work in Photoline!

[photoken]

My point is that your method increases the number of keystrokes and/or mouse actions:

Nope. It requires no mouse actions. It would require one additional keypress to switch the input focus between the Layers panel and the editing window.

There is just no need to activate the layer panel first for additional actions

Of course there is. You need to tell the program that you're finished moving layer content and now wish to navigate through the Layers panel.

[Herbert123]

My point is that your method increases the number of keystrokes and/or mouse actions:

Nope. It requires no mouse actions. It would require one additional keypress to switch the input focus between the Layers panel and the editing window.

Correction: your method would require at a minimum two additional key strokes to select a layer and move the contents in the main view. One to switch the focus to the layer panel, and use the cursor keys to navigate the layer list (because the user would be working in the main view initially). And one more to switch back to the main view in order for the user to move the selected layer content with the cursor keys. That is the real world usage scenario: I move content, and then I probably want to select and move the next layer content. This requires two additional key strokes in your scenario.

TWO additional key presses - which are unnecessary when we can use an alternative key combo to navigate the layer stack without the need switch input focus between the two. Which is also the way Photoshop works (which happens to be the industry standard).

And yes, your suggested workflow does require extra mouse-clicks and mouse actions! In the previous version I was forced to continuously zoom out and pan the view to find an area that was safe to click - I use the layer panel to select obscured layers and hidden layers. I would then have to activate the main view first to return the focus on the main view. I often work zoomed in, and I would first have to zoom out or pan the view and carefully click on an area outside the canvas - I had to, because I would not want to inadvertently activate the wrong layer in the main view.

Sorry, but it required many more clicks and actions on my part to activate the main view. And this will also be the case for anyone unwilling to use the keyboard shortcuts. It is a far too inconvenient workflow.

There is just no need to activate the layer panel first for additional actions

Of course there is. You need to tell the program that you're finished moving layer content and now wish to navigate through the Layers panel.

No, I again disagree - your point would only be valid if there would be a benefit to creating a separate focus between the main view and the layer panel.

An efficient and easy workflow that gets work done faster with less clicks and/or key strokes outweighs any perceived logical workflow.

Ken, if you can demonstrate that your workflow is more efficient than the current one, i.e.: less clicks, mouse actions, and key presses, then I will let myself be wholeheartedly convinced that your suggested workflow is the better one.

[beiti]

Wenn ich das richtig verstehe, wird die Ebene mit dem Ebenen-Intent in den Farbraum des Dokuments umgerechnet (nur so kann das Ergebnis mit den darunter liegenden Ebenen verrechnet werden). Beim Speichern spielt der Dokument-Intent keine Rolle. Bei der Ausgabe des Dokuments wird dann mit dem Dokument-Intent in den Display- oder Druckerfarbraum umgerechnet, auch bei der Wandlung nach sRGB beim Web-Export.

Meine Beobachtungen bezogen sich ausschließlich auf die Monitordarstellung.

Hier sind vier Screenshots und die zugrundeliegende Testdatei: http://downloads.abula.de/intent_vergleich.zip

Das Dokument hat als Farbraum ISOcoated v2 300% (CMYK), während die Foto-Ebene in sRGB vorliegt.
Ich habe vier Varianten der Zuweisung eines Rendering Intents getestet (an beiden Stellen jeweils perzeptiv und reativ farbmetrisch), und es kommen vier verschiedene (!) Ergebnisse raus.
Nach der jüngsten Änderung (19.40b11) hätte ich erwartet, dass der Rendering Intent, der dem Dokument zugeordnet wird, unberücksichtigt bleibt. Wo liegt das Missverständnis? Wie kann PhotoLine überhaupt zweierlei Rendering Intents auf dieselbe Konvertierung anwenden?

[Martin Huber]

Wenn ich das richtig verstehe, wird die Ebene mit dem Ebenen-Intent in den Farbraum des Dokuments umgerechnet (nur so kann das Ergebnis mit den darunter liegenden Ebenen verrechnet werden). Beim Speichern spielt der Dokument-Intent keine Rolle. Bei der Ausgabe des Dokuments wird dann mit dem Dokument-Intent in den Display- oder Druckerfarbraum umgerechnet, auch bei der Wandlung nach sRGB beim Web-Export.

Meine Beobachtungen bezogen sich ausschließlich auf die Monitordarstellung.
(...)
Nach der jüngsten Änderung (19.40b11) hätte ich erwartet, dass der Rendering Intent, der dem Dokument zugeordnet wird, unberücksichtigt bleibt. Wo liegt das Missverständnis? Wie kann PhotoLine überhaupt zweierlei Rendering Intents auf dieselbe Konvertierung anwenden?

Burkhard hat da schon recht. PhotoLine baut das Dokument in CMYK auf und bei der Ausgabe des RGB-Bildes wird das Rendering Intent des Bildprofils verwendet. Danach wird das CMYK-Bild auf dem Bildschirm ausgegeben, und dabei wird das Rendering Intent des Dokumentprofils verwendet.
Das heißt, es werden 2 Rendering Intents bei der Bildschirmausgabe verwendet.

Martin