Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Since the "Pre-1.8 Photo Bugs" tag was added to my post, I surmise that means version 1.8 should no longer exhibit the bug. If this is correct, please read on. I just encountered the same bug again, the version currently installed is I'm still not sure what I did to activate the bug; but I'll try to find out under what circumstances it reverts to normal operation (if at all). Tried changing the mesh percentage. Then dragged the image around using both the hand tool (which is what it's set to while the bug is active), as well as by holding down the space bar, then dragging. Finally, I hit CTRL+SHIFT (I believe) -- possibly preceded/followed by another nearby key -- and that changed it back to normal operating mode.
  2. Summary Many tools provide a preview mode, which shows the effect of using the tool prior to execution. This preview mode is very useful, since it allows the user to see the result of applying e.g. the erase tool, or a brush, etc. Unfortunately, it does not work consistently: it ceases to work if the user tries to draw a line that connects the previous application of the tool to its current position using the shift key. The situation is further exacerbated by the fact that the position of the previous application of the tool (the origin point of the line) is lost when a line is created and then undone (e.g. if the result is sub-optimal, which cannot be determined prior to execution due to previously mentioned inconsistency in the preview). Directions to demonstrate preview mode inconsistency On a blank canvas, move the pointer (set to any paint/brush/erase tool that allows the use of shift to create a straight line) over the canvas. A preview of the effect of the tool becomes visible. Left-click while on the canvas to apply the tool. Move the pointer some distance away from where it was previously applied. Now a preview in the new location is shown. Hold down the left shift key. Expected behavior For tools that can be applied in a line via the shift key, the preview should change to reflect the outcome of the line being applied; e.g. for the erase tool, it should show a line consisting of background color/transparency that connects the previous invocation of the tools to the new cursor position. Actual behavior The preview continues to show the result of applying the tool in a single location (located at the pointer position). But when applied with the L-shift key held down, the actual outcome differs from the preview. As I mentioned before, this wouldn't be so troublesome if the program reverted all internal parameters to the prior state upon execution of the Undo command. But Undo is inconsistent in that it only reverts visual changes, rather than all internally stored values as well (e.g. l coordinates of where a tool was applied in a prior step). Directions to demonstrate inconsistency in program state Load an image, then use the erase tool in line mode (L-shift) to remove part of it (e.g. for isolation of a foreground object contained therein): apply the erase tool to an origin point, then hold down L-shift to remove the part of the image that forms a line from the origin point to the current pointer position. Execute the Undo command (CTRL-Z). Holding down L-shift, apply the erase tool once more. Expected behavior Upon executing undo, the previously created line is removed. Furthermore, applying the tool with L-shift held down should once again create a new line stretching from the current pointer position to the position where it was applied in step 1. Actual behavior The line created does not connect to the point created in step 1, but rather to the point where the tool it was applied in step 3. This is not only inconsistent ("Undo" only reverts some parameters to the previous state, not all), but unfortunately reduces the utility of applying tools in a straight line, since the origin point has to be recreated in its previous location (sterp 1), which frequently cannot be done easily/consistently (e.g. if the tool applied uses an alpha gradient -- which includes essentially all tools that can be applied as a line).
  3. I apologize in advance because I cannot reproduce the bug deterministically. I only know that it happens frequently, that it usually (again, due to unknown factors) resolves itself, and that, during the most recent occurrence, it did not -- although, apparently, saving/reloading the image did reset the issue (i.e. I did not have to exit the application). Description: while using liquid persona, I frequently enter a "mode" where, regardless of which tool (hand, zoom, push, twirl, pinch, etc.) is active, only the hand tool is in effect at all times (unless I use modifier keys for zoom or horizontal/vertical scrolling). This happens frequently and may be caused by accidentally hitting "invalid" combinations of modifier keys (e.g. accidentally holding down the windows key , or perhaps one or more nearby keys along with the intended ctrl/shift/alt used for additional functions/movement). In those cases, only the hand tool becomes visible and regardless of changing other settings within the liquify persona parameters (radius, rate, or even ramp function, view, or mesh percentage), this last time I was unable to use any other liquify tools until I saved, closed, then re-opened the image. In other words, even selecting apply to return to the photo persona, then pressing the liquify persona button to get back into that mode did not correct the behavior. On previous occasions, I was somehow able to get out of this mode -- although the method eludes me (I generally clicked on other tool icons, then tried tools in combinations with modifier keys, and sometimes it would go back to showing the circle that indicates that one of the modifier tools is in use. I have found nothing in the preferences (including hotkeys section) that appears to freeze all photo manipulation functionality. In addition, I have attempted to force the behavior by mashing various keys in the lower left section of the keyboard, but have yet to find the precise set circumstances that cause this behavior. I can only say that it appears to happen at least 50% of the time that I use the tool. I will update if I find more a deterministic way of reproducing the problem.
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.