Jump to content
You must now use your email address to sign in [click for more info] ×

m.vlad

Members
  • Posts

    203
  • Joined

  • Last visited

Posts posted by m.vlad

  1. 1 minute ago, fde101 said:

    Those are for imported files, not for the newly created/modified document content.  In the case of RAW files you have the option of linking to the existing RAW file, for example, instead of copying (embedding) the RAW data into the Affinity Photo file.  This helps to reduce consumed disk space by not storing an extra copy of the data, but also means that there is a dependency on the existing, external file to be present in order to make use of the document (afphoto file).

    Thanks that actually clarifies quite a bit!

    2 minutes ago, fde101 said:

    That is going to happen anyway; even if Affinity Photo did save your RAW development steps in an XMP it would not be usable in anything else anyway since nothing else would reproduce the same processing that Photo would have done on the original RAW data.  About the only thing you could really trust to be usable would be metadata (author/copyright info, etc.).

    True, but an xmp can be approximated. It would also mean smaller file sizes.

    4 minutes ago, fde101 said:

    This is already possible as long as you use a RAW layer instead of a pixel layer when developing.  The crop tool in the Develop persona can be reselected to regain access to the previously cropped data.  If you use the crop tool in the Photo persona after developing, you need to check the Reveal checkbox on the context toolbar to see the hidden parts of the image which were previously cropped out.

    That sounds very confusing, it should just work like an artboard crop ootb.

    5 minutes ago, fde101 said:

    There is a split view available from the main toolbar in the Develop persona which compares the current image with the image as it was when you entered the persona.

    But what if you develop the image, go back to the main persona, then reopen it? I'll test a bit later, I couldn't see a split view option earlier but it's been a while since I've used afphoto.

    7 minutes ago, fde101 said:

    An Affinity Photo document is not a RAW file.  It is more like a Photoshop document.

    When you open a RAW file it lands you in the Develop persona to develop the RAW data, and the "Output" setting on the context toolbar defaults to a pixel layer.  If you leave it that way, when you develop the image and return to the Photo persona, the RAW data is thrown away at that point and you are left with a non-RAW image ready to be further modified.  If you change it to a RAW Layer instead, then the RAW data is retained and the layer containing the RAW image is a RAW layer, which is indicated if you hover the mouse over the left edge of that layer in the Layers panel (where most other layer types have an icon to indicate what type they are, for some reason the RAW layers seem to have a blank icon right now, at least on mine).  As long as you leave it as a RAW layer, you can go back to the Develop persona to further adjust it, but most of the editing tools in the Photo persona will not work on that layer without first converting it to a pixel layer, at which point it loses the RAW data and the edits become destructive.  (You can place other types of layers over top of it, however, including adjustment layers and live filters, and any of those layers can have masks to adjust selected areas, so in the end the available functionality when working non-destructively with RAW data - which is what the RAW layers offer - is similar to that of the tools you mentioned, but without the benefit of catalogs or an image browser of any kind to assist with culling or with working between multiple images).

    I am aware it's not a raw file, maybe my message wasn't clear enough, I meant to say the raw layer is not clearly labeled as such in some way (no, the tiny icon to the side is not enough), you just have to know that this one layer, when selected, allows you to (re)develop it. There was no need for the rest of the paragraph. For one, I am already aware of the features the app has, as I've watched their "what's new" video series - the only part I found confusing was no.1, and only because it's not too clear by itself what those mean. Secondly, I already addressed how my complaints go further than "no DAM bad". So far the raw editing is slightly better than camera raw, but still only works when the intention is to do a few small tweaks before actually doing photo manipulation and the like, instead of being a fully fledged raw editor with the option to take that further. It is no photo editor replacer for me, at least not in its current state, though I'm optimistic it could be at one point in its V2 lifecycle.

  2. 11 hours ago, rparmar said:

    Hello, did you notice there's only one forum? Translation apps are free. Chrome will even do it automatically. Expand your world.

    Considering everyone else is speaking english, and this is primarily an english forum, it should be on them to translate their comment, even badly, to the rest of the audience. I'm saying that as a bilingual and non-english native.

     

    Anyway, with that out of the way, after using the apps a bit, while I do appreciate the splash of colour, the old icons had a much much clearer silhouette compared to the new ones, where we have fancy gradients, strokes, and overall an uneven visual language, with some icons being overly complicated (the transparency tool icon in AFDesigner, shape builder tool, zoom tool, and artboard tool among others) and some being reduced to a stroke (all the shape icons, which went from clearly standing out filled shapes to outlines with a slightly darkening fill). While the old ones didn't pop as much, they were much more even. Also for the general flat design direction - while it feels more "modern", input contrast is severely impaired, with buttons and other inputs standing out quite a bit less than before, though this could easily be fixed with tweaking some UI colours (looking mainly at the top bar, the paragraph tab is a good example of how increasing the contrast can make things stand out without the need of the skeuomorphic outline).

  3. First of all, thanks for these updates, excited to try out the tools! I do have some issues that I've found after an hour of trying to use this as an alternative to other photo editors that I'd hope to see addressed:

    1. A way to save raw edits as XMP instead of requiring the saving of an .afphoto file, the idea of closing down in an ecosystem, particularly with the lack of a DAM, doesn't sound appealing. It sounds like that's kind of what the Embedded and Linked options do, however the Linked option did not actually add any files to my system (I kept watch on any files with the same file name as the photo), so I'm unsure what the difference between the two is.

    2. Global presets for RAW edits, instead of one per page. It's a bit confusing as is. Also a way to edit existing presets and save it as such, instead of deleting a preset, remaking it from scratch and saving that. Also this is likely a bug, but when opening a new raw file to edit, the settings are set to Default, but the "selected" preset is the last used one, requiring switching to Default and back to the saved preset to actually change things, sometimes even doing it multiple times, the feature seems quite buggy. Also, ideally a Preset Manager would also be present, to be able to see exactly what each preset does, and potentially tweak from there.

    3. Non-destructive cropping is a must. Honestly just something similar to the artboards, so if you crop an image you can adjust the crop later. I could just open the file in ADesigner, but that's an extra step that could be avoided.

    3.1. Keep a strict ratio for cropping, but allow to rotate the crop based on mouse position when dragging the crop selection around (see how cropping operates in other apps like Lightroom and Capture One).

    4. Split view of photo without edits, or just being able to toggle the raw edits on and off for preview purposes.

    5. It's not clear enough that a photo is a RAW file, a button similar to the FX one would work wonders and make it much clearer what it does.

    6. There's something about the Overlays panel that feels incomplete, I think it should be closer in look and feel to the Layers panel but then again, how is this better than just duplicating the layer, making the adjustments in that raw layer, and applying a mask to that? Even more powerful then because you can use images and the like.

     

    I might add more to the list once I spend more time on this, but so far I'm somewhat disappointed. Non destructive raw editing was a highlight of the announcement, so I thought it's finally a good standalone photo editor. It is clear however that the app development is still walking in the shadow of CameraRaw and while there have been some improvements and additions that are much welcome, I'm sad to say that I'll likely be sticking with Capture One, despite my wishes for that to not be the case, not because of the lack of a DAM (just making that clear), but because of the lack of a good, non destructive, open photo editing flow.

  4. On 9/7/2021 at 4:50 AM, Mark Oehlschlager said:

    @tallrob Because any IDML export (from InDesign to APub, or from APub to InDesign) is not likely to be interpreted 100% correctly by the target application, and because certain proprietary features of both applications will get dropped in translation, the primary utility of an export to IDML feature in APub is simply to make it possible to deliver an APub document to an InDesign user with 95-98% of the design and layout in tact, saving a ton of time that would otherwise be spent recreating the document from scratch.

    Because the translation can never hope to be 100% accurate in any but the simplest of documents, the IDML export feature that many people here, including myself, are requesting should probably be thought of as a one-time, one-way export function. For obvious reasons, continuous round-tripping a document between InDesign and APub would introduce translation errors with each exchange and require time to repair the translation errors. That could get tedious and discouraging, adding unwanted friction to a collaborative workflow.

    Having said that, I still think there's a strong case to be made for Serif building or licensing an IDML export feature for APub. It means that APub users (and prospective APub users) can feel more confident in committing to using APub and the rest of the Affinity Suite for publishing and design, knowing that if they must hand off an APub file to an InDesign user, there is a compatible exchange file format in IDML that will keep at least 95-98% of the document design in tact, if not 100%, and thus being able to share one's work while minimizing any necessary format corrections in InDesign as a result of the translation.

    The alternative scenario, not having an IDML export feature in APub, means one must either commit to the cost and the time spent learning two applications (not something most people would choose), or committing to the cost of just one application – and for most, that means reluctantly abandoning APub for InDesign because it has the advantage of being more mature tool and an industry standard.

    To be honest, even a slightly broken export feature would be better than none at all. Forcing people to move their entire production to a specific software is not ideal, especially when your app is new in the industry. You cannot expect people to just drop open industry standards in favor of closed source formats from a younger app, especially when there's no reason to have it locked to that format in the first place.

  5. Hello, I've noticed a consistent behaviour where the app freezes when using the scroll wheel to scroll through the slices in the export persona. Using the scrollbar shows no problems. This happens no matter what state hardware acceleration is in. This has been happening for a few versions now.

    To replicate, create/open a document with enough artboards/slices to overflow the panel so that you need to scroll through it.

  6. So I have the following pdf: https://drive.google.com/file/d/1X93xwzcKEjJUkoPh51UCQLOCUVvA7hIR/view?usp=sharing

    When exported from the latest beta, the first page and a couple parts of the following pages end up getting rasterized.

    Opening the document in the latest release however and exporting with the same settings yields a proper pdf with non-rasterized images. Here is how an export from the stable build (the one without a dash) looks like side by side with one from the beta build (the one with a dash). The beta build only has 1 Image layer for the entire page.

    image.png.ad0c24c4d444e37f50fa6cfc22c6f623.pngimage.png.9e216d9c6925fadc24800ef1e2bda2af.png

     

    I hope this can be fixed.

    narsil - readme.pdfnarsil readme.pdf

    Here are the pdfs as well, for comparison:

     

  7. 5 minutes ago, wonderings said:

    Not sure anyone here is against a Linux version, what I think people like myself argue is that it may not be a good business idea for Serif to go down that route at the moment. It is also not just some easy thing to jump into and just start raking in the money. Sure you could go and block anyone who disagrees with you but I would say that is a sad way to live your life, only allowing things in that you agree with already. Are you not open to hearing other view points and either strengthening your own or changing based on something that may actually make sense?

    I think the more options for consumers the better, so in this I would say it would be great if Linux users had an option. For a business I am not sure it is worth it at this stage for all the reasons that have been listed by others who you would throw into the "troll" category. Civil discourse can be had and is incredibly healthy. What is not healthy is again blocking out any opposing views.

    Their points were refuted again and again, you can have a civil discussion without having to agree on something. If they don't provide anything productive to the conversation and only serve to annoy people for having different opinions, then they can speak in their echo chamber. Bringing up different viewpoints and opinions is all good if it is in good faith. People have previously brought up that they don't want affinity to divert resources to support a different OS when they could instead work faster on updates and features for the current OS lineup. That is a valid reason, it goes against the topic in a way, but it is a valid opinion, and we have in turn reacted with suggesting looking into the compatibility issues with WINE instead of a full blown port. This is how a mature conversation goes, not ad hominem attacks and repeating one's point until the other side is too bored to repeat so you decide you've "won".

  8. 4 minutes ago, LondonSquirrel said:

    From Affinity: I won't rule out making a Linux version of Affinity, but I need someone to show me a combination of distro, desktop topology and deployment (paid) platform where we would recoup our development costs. If someone can show me that, I'll be willing to talk some more about it all..

    So, for the Linux supporters, if you can come up with that combination you may get your wish. Until then, your comments are off topic.

    the issue is that question was already addressed repeatedly, you might've missed a few pages. I'm not wasting more time looking for the quotes however, you can look for them yourself.

  9. 11 minutes ago, LondonSquirrel said:

    No, that was your claim. Your words, not mine.

    My words: The fact that Nvidia make well performing drivers really annoys him (Linus Torvalds).

    5 hours ago, LondonSquirrel said:

    As though Nvidia owes Linux anything. Remember the desktop share: Linux is nowhere. It's unimportant to Nvidia.

      

    11 minutes ago, LondonSquirrel said:

    It is flawed. Even Linus Torvalds has trouble getting his software to install reliably on Linux. There are simply too many distributions, too many windows managers, too many kernel versions, too many this that and the other to make installing on Linux a reliable option. It's called fragmentation. It's a horrible mess on the desktop. Server side it is good, though not excellent.

    I had to double check to make sure I wasn't quoting the wrong thing. This is made up of either false assumptions or things that aren't necessarily better on Windows and it was addressed before (quoted below). Please don't bring up your points again unless you add something of substance to them.

    On 4/12/2021 at 2:17 PM, Redsandro said:

    It is an open source component. The entirety of Linux consists of open source components made by multiple parties. By calling it a third-party kludge, you indulge yourself to a mind trick that can be utilized to criticize every single Linux component.

    Let's Torvalds directly: I finally got around to play with the "AppImage" version of +Subsurface, and it really does seem to 'just work'.

    An AppImage is a self-mounting filesystem image conceptually like a macOS .dmg file. So if it's good enough for OSX, you're just really bending backwards to criticize a good solution to an ancient problem.

    Hohndel: [Mac got] this right. I control the libraries my app runs against. [...] With an AppImage I can give them just that. Something that runs on their computer.

    On 4/12/2021 at 2:17 PM, m.vlad said:

    but then you have bloat in your system, libraries that are only needed for a few applications that might not be needed anymore but are packaged in because of reasons. Otherwise you already have dependency installations with most distros, where installing via the package manager will install the dependent libraries with a "dependency" tag that is then uninstalled together with the app when that is not needed anymore. Sure AppImage isn't the best, but it's one of many solutions and while it won't work for everything, it will work for a few small apps. To me this just sounds like moving the goalpost. "we can't port this app because there's too many distros" "look, this is a way to port the app to many distros without testing for each one" "we can't port this app because the solution you provided would include redundant code". the point isn't to give the perfect solution, the point is to have a solution to start from, together with snap packages and the other solutions.

    Piggybacking on what Redsandro said, if appimages are third party kludges, what is first party when it comes to linux? Where do you draw the line of first party and third party when it comes to an open source environment where everyone can contribute and fork and push changes and fixes and features?

    On 4/12/2021 at 2:21 PM, Renzatic said:

    Yeah, but you do run into similar situations even on Windows, when you find yourself having to update to a later version of, say, .net. The only difference there is that Windows does a better job of making that upgrade process automagical, while Linux just tells you that you need a later version of the library, and leaves you to find out how to do it.

    Like I said, it's mostly an academic argument, because at the end of the day, it isn't any more difficult for developers to implement, and doing so doesn't make the app any slower or less efficient. Literally the only difference is that your raw tar.gz version which only includes the binaries is 120 meg, while the appimage is 135 meg.

     

    16 minutes ago, LondonSquirrel said:

    Correcting false claims.

      You're supposed to bring proof when correcting someone, unless it's something that's so blatantly false that it's common sense for it to be that way. I think the only source you've mentioned here is the desktop usage stats, which you haven't even linked to, but since everyone knows about those everyone can infer which one you're talking about

     

    16 minutes ago, LondonSquirrel said:

    No I have never said that. Those are your words. Again. The thing is, which you will not admit, is that the Linux desktop market is very small. Affinity knows this, which is why they asked more or less for proof that it is worth developing for.

    Can't find an exact quote for this, but considering your consistent posting and lack of understanding and open mind to solutions (I seriously had to go through 10 pages of comments to bring up the replies that refuted a point you brought up before. Either learn from it or stop posting) I am inclined to say that if I had to quote something to refute this, it would be the last 10 pages of your comments that show an attitude of superiority, ignorance and most of all stubborness of being in the right, even if you're retreading the same ground (repeated questions of either your own posts or other people who've already asked the same questions) or making statements that are common sense (the bit about the linux app library being smaller, because surprise, it's less used so there's less people making apps statistically speaking).

  10. 31 minutes ago, ClairelyClaire said:

    Now, to recenter this thread on the subject at hand - which has nothing to do with you, I'm sad to say - I would be very interested in being part of any potential solutions or roadmaps, even if just in the arena of finding bugs (which I'm annoyingly good at). I'm sure I'm not the only user who would be interested in contributing, too!

    the bugs on the affinity photo are where there's more substance to what needs to be fixed for Affinity (and other apps) to work:

  11. Just now, Renzatic said:

    Serif already sells the Windows versions of their apps off their own storefront, which I imagine provides them all the analytics they need. Providing a Linux version alongside it probably wouldn't be that difficult. Though Steam is a good 2nd option, since it's unofficially the official proprietary app storefront for all Linux distros.

    As for libraries and whatnot, targeting a single distro, like either Red Hat, or Ubuntu, as a support foundation, then releasing either a flatpak or .appimage with all the libraries included would be the path of least resistance. That's pretty much what everyone else does these days.

    It's a shame we can't just pin things in this thread in a way, because that's what's been said for pages now, yet people still ask for solutions and options and release channels.

     

    I mentioned Steam because it's a pre-existing solution that's already embedded into the linux scene.

  12. 2 minutes ago, LondonSquirrel said:

    Please try to stay on topic. Affinity stated: I won't rule out making a Linux version of Affinity, but I need someone to show me a combination of distro, desktop topology and deployment (paid) platform where we would recoup our development costs. If someone can show me that, I'll be willing to talk some more about it all..

    So, they want a combination of:

    • distro
    • desktop topology
    • paid platform support
    • all of which must recoup their development costs

    If you can't show that, you only have yourselves to blame.

    You could put it up on Steam, that would solve the paid platform problem, offer analytics support and work on most platforms due to steam handling libraries itself.

    ...also "we"? What would you be recouping as a user?

  13. Just now, LondonSquirrel said:

    Nonsense. What Linux lack is professional apps. Not another notepad app, of which there are hundreds. The proof of the pudding is in the eating. Linux on the desktop is insignificant, which is precisely why there are so few professional apps available for it. It has been like this forever.

    So you agree that what you're saying is linux lacks professional apps and that its userbase is insignificant because there's few professional apps on it, therefore adding more apps to its portfolio should, in theory, based on your argument, increase its userbase.

    I will remind you that we're here arguing for a port or a version that works through WINE of a design app that would fill in the gap of graphic design work on linux. Sure making a point about how big the linux on desktop is could help the argument, but that can always be refuted with "but it's just 3% anyway", which is what I feel is happening here when you're moving the goalpost. There's tens of vocal people who say they'd switch to linux if affinity or adobe worked well on linux, that's just in this forum. There's probably hundreds of people who would do it but aren't vocal about it. This is definitely a viable market considering Serif just has to work with the people who work on WINE and make themselves available so that Affinity works on linux. This isn't a monumental task, and the benefit would outweight the cost (specifically in the case of making it work with WINE/CodeWeavers, I'm not talking about fully porting the app to linux).

  14. 48 minutes ago, LondonSquirrel said:

    The Linux desktop (which of them, or all of them) lacks apps. The number is insignificant in comparison to Windows or Mac.

    You're arguing that a desktop that has less than 5% overall usage has less apps like it's a revolutionary fact. "Linux desktop really lacks very little" was about niches solved by apps, not about how big a number is. What Linux lacks most (excluding professional graphic design software) is competition and variety within its niche apps, not thousands of proprietary apps. To get a functioning workstation going you're not gonna install all the apps available, you're gonna install one-two apps for whatever you need them for: browsers, archive managers, professional software, office software, etc.

    Therefore I think your argument ignores this and makes it about how underdeveloped an overall underutilized OS is, which isn't relevant, graphic designers aren't a majority of the windows or mac os users, and the app portfolio of these two operating systems is not primarily filled with distinct design tools for the amount of them to matter.

  15. 33 minutes ago, LondonSquirrel said:

    Much of this post is proof that Linux users inhabit an alternative universe. They are unwilling to accept a few simple truths. Linux has its place, but it's desktop share is so small that it is not worth producing software for it.

    I think it would be productive to bring some arguments before you hit us with your conclusion.

    22 minutes ago, ewwn said:

    I disagree, its not worth supporting closed source software for it, because there is a good amount of Linux users who just won't use closed software

    If affinity was open source (not reasonable) it's simply not with it for the 1% that use Linux and are ok with closed source

    You need sources when you make a strong claim like that. Where is the 1% from?

  16. 3 minutes ago, LondonSquirrel said:

    Err, it shows whether a market is viable.

    Because I've heard it all before. It's the same argument over and over and over and over. And it is nonsense. My 'conjecture' as you put it is 'reality'. The 'year of the Linux desktop' is a meme. I just did a quick search for it. So 2020 was going to be the 'year of the Linux desktop' according to this dude.

    1546899538_Screenshot2021-05-28at18_29_09.png.01a543700c3f8bd764e8f2985da49832.png

    And this delusional post for 2019:

    375338830_Screenshot2021-05-28at18_30_16.png.75d3b074a9f01b8f71c7c6c6572e7e7c.png

    I've heard it all before. It goes back years years. I can't remember when I first heard it.

    Making the graphic design sector be fully viable on linux is very different from "the year of linux" thing. Affinity is definitely not the last gear to making linux boom and multiply its userbase by 10x. We're just talking about the people who need a graphic design software, be it VFX artists, graphic designers who want to switch to linux or smaller businesses who'd rather get Affinity on a free OS rather than pay for adobe on windows. We're talking about very different goals here.

  17. 15 minutes ago, LondonSquirrel said:

    In response to m.vlad and Michael Tunnell, Linux on the desktop is very poor in comparison to Windows and MacOS. Very few people are crying out for good graphics tools on Linux. Those that do, and have done for the last 20+ years for this app and that app, significantly overestimate their numbers.

    The vocal part of a group will always be the minority. There will always be people that think of the same issue but don't actually go and voice it. Hence the entire reason people have been asking for some sort of kickstarter so that people can put their money where their mouth is. a kickstarter would also be easily shareable and could be covered by youtube channels and blogs so it gets to the people who aren't vocal.

     

    15 minutes ago, LondonSquirrel said:

    If there was a viable graphics market on Linux, Adobe would be there. This supposed market of the Linux desktop simply does not exist. For Affinity to devote time, money, and resources to making Linux versions of their apps would be a waste of money.

    We don't know why adobe isn't porting their apps. I could equally say "their portfolio is too large and their current profit margin is good enough for them" or "they don't benefit from a core code because all of their apps are built different", or even "They're ok with the current WINE portability of their apps" but that's all hearsay. All we actually know is that they said they won't do it.

     

    15 minutes ago, LondonSquirrel said:

    It isn't just graphics software, it's all software on the Linux desktop. Take a look at this wiki page: https://en.wikipedia.org/wiki/List_of_proprietary_software_for_Linux. One wiki page proudly lists proprietary software for Linux. I don't suppose it is complete, but ONE PAGE... And quite a few items listed are shown as discontinued.

    Self fulfilling prophecy. You're saying a proprietary app should not be released on linux because there aren't "enough" proprietary apps. Even if there were similar pages for windows and macos, i'm not sure you would use even a quarter of the ones on their list, so are you just looking for a ton of apps for no reason? Well just run an android emulator on it, you'll get access to tons of bloat!

    anyway I don't see why this matters. Why does quantity matter in this argument? Just looking at the fact that the big VFX companies use linux, or that blackmagic is still selling their apps on linux, considering they're in the same visual industry, is a stronger argument than linking a list of proprietary apps. Also such a list doesn't factor in apps that work via electron (such as figma, a UI design solution) which are proprietary but not "released" on linux.

     

    15 minutes ago, LondonSquirrel said:

    So please stop pretending this market exists and Affinity can take over the world if only they would make versions available for Linux. I've heard it all before. It's nonsense.

    And how did you arrive to this conclusion when all you've been saying is conjecture and dismissing what the others are saying?

×
×
  • Create New...

Important Information

Terms of Use | 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.