Jump to content

hifred

Members
  • Content Count

    398
  • Joined

Everything posted by hifred

  1. Here's one more – this has not to do with inapropriate tool states causing irritation – but a lot with getting trapped. Affinity Photo lets us embed external images and layered documents, which are not rasterized and therefore may get losslessly transformed. As a consequence the layer isn't directly editable with tools which require rasterized data. Understandable as well. What is not understandable and what again makes perfect traps for anyone who knows similar features from other applications is that one on embedded content... cannot create raster copies from selections may not apply sort of pixel based manipulations/corrections on layers above (stamp, heal, blur...) Right now all these operations just fail and the program gives zero feedback why this happens. Altogether these make for dozens of possible situations where nothing happens on screen and users – especially those coming from Photoshop – have no idea what the heck could be wrong. The very first step in the right direction would be that you showed an info that you that the source layer needs to be rasterized. The actual solution was to avoid such situations altogether. Other programs perform instant rasterization for the required operations, so that one may retain the encapsulated object as is and still manipulate it at will – on layers above. This auto-rasterization has only advantages over what Affinity Photo does currently. What certainly is not helpful at all is to rasterize the external content via (default) assistant – without even asking. But that's actually happening. Is there btw. already a way to send embedded documents to external applications for further editing? I have not found how to do this. I also updated embedded documents with 3rd party apps but Affinity Photo neither auto-refreshed the embedded file (seemingly no no embed + link functionality) nor lets me perform the update manually. Have I overlooked anything?
  2. I'm not sure that I understand you properly – but a standalone DAM will certainly be of good value for AD and AP-users too.
  3. This has been discussed before, earlier in this thread. A few users would prefer an inbuilt option, but Serif already stated that the DAM will be a standalone product. To me this makes a lot of sense.
  4. Well, this is a matter of definition. I only wrote about malfunctions in existing features. I consider standard-tools which bring users to a point that they can no more track down the issue themselfes defective – as the present tool-behaviour does not offer the slightest advantage, in any context.
  5. The more I tinker with Affinity Photo, the more I run into bad, but quite easy to fix traps. Some of them are caused simply by the fact that a tool behaviour remains stuck the inappropriate positions, so that they block editing in later stages of the project. Here's two: 1) Recently I found out that selection-tools stubbornly remain stuck to their previous Subtractive state even if the user wants to create a fresh selection. The operation fails, although the user has picked the appropriate tool and also has performed the expected motion. Here one badly needed an exception to the rule – selection tools have to create a selection if the tool can not find anything to subtract from. Others suggested that Affinity should beep or show a dialog and by that inform + CTA the user that the tool is in the wrong state – but that would be horrible UX. At that point you could also abolish your assistants too. Don't make me think, don't ask for pointless decisions and action if there's exactly one expected behaviour: Making a (fresh) selection. 2) Today I saw another thing which is even a lot nastier as there's not even a suble visible indicator. One may hide selections (hide the marching ants), which is great. But that hidden state even remains active when the user wants to create a new selection. Such really may not happen. There's absolutly no workflow imaginable where this made sense, this is just a trap and nothing else. A hard to understand trap – imagine you had a selection hidden and go to lunch, afterwards you pick a selection tool and run into what's shown in the GIF. Selection tools always have to revert to state=visible whenever a selection is dropped. Is there anyone in charge, exclusively for little usability-killers of that kind? It would well be worth it.
  6. Is it possible in Affinity to call a tool with a particular setting with its own hotkey?
  7. Thank you. Sorry for misreading – the screenshot helped.
  8. I have now also tested Combine. That is still not the exactly same, insofar as all paths are initially drawn on separate layers and need to get reselected and combined by hand to put them one one layer. I usually prefer using the Lasso tool on a Cintiq over drawing vector selections anyway, but the 1.7 behaviour doesn't equal Photoshops path tool.
  9. Oh – I see that is intended as boolean operations. First create various paths which all get their individual layers and then merge. I think what the OP wants is more how paths work in Photoshop. Any number of curves are automatically drawn as one unified object and may get converted to pixel-selections and masks.
  10. Thanks for that, but I don't get this to work in the latest Windows Beta. It's always greyed out.
  11. Walt, while I have not tested this myself, this seems not at all unrealistic. Here's a Lightroom migration guide by a competitor.
  12. I fail seeing how this is couter-intuitive. What Photoshop does may not be strictly logical in a mathematical sense (as an exception to a rule is made) but it's very deliberately there and it prevents all users from error - that's what counts. Realistically, pretty much every Affinity-user will at least issue one failed selection attempt before discovering the wrong mode, this will sum up to very many needless clicks and decisions a year. It's your job to avoid these. Some users obviously even fail to decipher the modified cursor and need help, others get annoyed by such blatant weaknesses.
  13. But that's a terrible and utterly needless trap MEB! A bug that would be trivial to turn off. Subtract from selection in no context makes sense without a pre-existing selection. That mode may therefore not be active, unless a state is established, which justifies it's existence.
  14. I can't test this myself currently - but the actual question is why Rudy doesn't see the marching ants on newly created selections. If Hide Selection was involved: Is its implementation possibly sticky, so that it also affects completely new selections as well? If that was the case I'd consider this a bad usability bug. Hide Selection should only work on what's currently selected, new selection should turn the command off.
  15. It is painful to see how stubbornly you refuse good arguments. I should have been smarter.
  16. Yes, it is. Therefore the most helpful answer is to tell him that this functionality isn't available and that it can't get substituted either. So I did. I will stop here, have nice day.
  17. Or at least look at the attached gif: The sequence of actions here: Select RAWs for processing and use one of them to establish a global correction. It could be hundreds if you want. Select one of the images to perform a correction (I only increase blacks here) select all frames and click synchronize One typically may choose, what settings are transferred, which is more flexible than running a Macro On pressing "Done" selected modifications to the appearance are stored in a dataset associated with the RAW file (either sidecar or database). The RAWs remains unaltered, no images get output. But you can preview all manipulations in the DAM and get an indicator that the file was processed. All changes are re-editable, on single files or on any new selection of multiple files.
  18. I think did read carefully enough. Batch developing (without exporting images) means nothing else but applying the same edits (quote) to any number of RAW files. How about trying this all out yourself (outside of Affinity) instead of just talking about it?
  19. That, as stated before is often not desireable - and not what anyone in this thread asked for. I also gave you a sample of file writing with RAWs intact.
  20. While this is not correct in the case of PSD (as it can embed all supported RAW files, along with their settings), I spoke of batch developing without saving to an image. Development yes, image none. Develop settings in that case are written to a little text based sidecar file, or alternatively to a database - that's why the process may run so fast.
  21. Yeah maybe, but one very often doesn't even want to write an incompletely processed, static image, which no longer holds the original data set and editable settings. Batch processing is often understood as a common starting point for further individual, per frame corrections - on the RAW data and inside the RAW editor. Besides being extremely slow, any batch processing on RAWs currently is inevitable lossy with Affinity.
  22. Thanks for the clarification @walt.farell. I had assumed, that the OP wanted to do what one most typically would expect from batch processing RAWs. That's certainly not bringing RAWs unprocessed into the Layer based workspace (by circumventing the RAW processor) as suggested by @v_kyr. I frankly did not even consider this option - for me batch processing RAWs would mean working on the RAW data. Another often expected characteristics of batch processing RAWs is, that the same settings may get transferred to hundreds of files - within seconds. That's entirely impossible as well, with Affinity Photo.
  23. This is false info. There's no batch processing for RAW files in Affinity Photo (no Macro support in the Develop Persona). Using presets would mean having to open files manually, one by one - which is (by far) the most time-consuming part.
  24. I do remember and agree with every word - I'm just not sure how effective such forum feedback really is. Is there someone who looks for repeating feedback pattern and picks up ideas also outside the feature request forum and puts them onto a list? We don't know. Just a few days ago I commented in a thread which had a well chosen name and already went on for more than forum page. I happened to get an answer by a staff member which made clear to me that the underlying issue wasn't understood yet. In that case, with my answer I was able to sell the idea, but I tend to think that such is rather the exception, but the rule.
  25. Well, that's the whole purpose of making this layer/ mask preview size editable in PS, AI, IN. If you work with very many layers regularly you can decrease their size - if not - by all means make them big. It should be the user who decides what too much scrolling means. Good Layer filters and Search help too. Right now the small and hard coded square thumbnails are top reasons why I find the Layer Panel difficult to read - already with just a few layers.
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.