kinvermark

BTW, Adobe, through p-shop, Bridge & camera raw has had this capability for more than a decade. And YES there is a high demand for it. It is a flexible, professional workflow that saves people time... and money!

All sorts of image processing applications use adjustment layers and/or nodes to make non-destructive adjustments to a wide variety of media types. The claim that it cannot be done unless it is raw is simply not true.

Via the DNG.... I explained that from the very beginning, but perhaps as it was in response to "Old Bruce" and a continuation of another thread (that you were a part of ) this has been misunderstood. To reiterate: the FACT that a DNG created from tiff or jpeg files can be non-destructively edited in the develop persona provides evidence that this is technically possible. It is not an ideal workflow nor am I recommending it or asking for it as a feature request. The generalization of the feature request is simply to support - in some way - the non-destructive editing of jpeg, tiff, etc. in the same manner as RAW files currently can be edited in the develop module. Serif can call it something else if they want, but given that they already support jpeg, etc. (destructively) in the RAW develop module they may prefer to keep naming consistent. So as paulie.reklama 's idea - its just same thing with different name.

Que? Now you are talking about linked v not linked? This is getting silly. The conversation is about using non-raw in the develop persona in a non-destructive workflow. Obviously that means they must be linked! PS Somebody please try the workflow I have described and share your results. Thx.

Clearly this is where your theory, and my practical reality diverge. Try this: Use Bridge to convert a few tiff's to DNG. Bring those into Affinity Pub. Use the Photo develop persona to alter them (e.g. turn sat to nil) and commit the changes NON-destructively as "linked." They will show up in Publisher as altered. Now go back to the Photo develop persona and alter them again or reset them to original. Whatever. You can do this ad-nauseum until you want to export your final doc. No pixels are harmed.

@ R C-R As per the document you linked... "JPEG is often embedded into the RAW file, and may be full ... resolution" I am not suggesting this as the ultimate, best workflow, I am offering evidence that it is certainly technically possible. What I, and many others are asking Serif for it to extend the far superior workflow now available to raw to include non raw. What I do mildly object to is when forum members self-appoint as "gatekeepers" and continually knock back requests that they do not find interesting or cannot conceptualize the need for due to some strange myopia. This is a bit condescending IMO. I would like to hear from the Affinity team about this - not another forum member who has no decision making authority; that's pointless.

Not true. As I have pointed out previously, you can already edit DNG non-destructively in the develop persona and DNG's can already contain tiff, jpeg , etc. The problem is this workflow adds an extra step (e.g. convert jpegs to DNG in Adobe Bridge) and the DNG support in Affinity is a little wonky (WB is off, maybe some tone issues?) BTW, an optimistic " reading of the tea leaves" would be that once Serif gets these non-destructive workflow issues worked out they can connect an Affinity DAM via studiolink and have a really great integration for working with larger numbers of photos.

1) You get a more streamlined workflow. The equivalent converse argument would be for you to just develop your raw files BEFORE you use them in Affinity. Would you like that suggestion? I mean THAT would save Serif a lot of work 😉 2) managing "bloat" & feature planning are Serif's purview not yours; you simply don't have all the necessary information to form a valid opinion on this. 3) Non-raw is already supported in the develop module, just not with linking/embedding. This is a MAJOR WORKFLOW IMPROVEMENT! 4) The "photographers love raw" position was predictable; try looking at this from the point of view of a designer who gets ALL KINDS of files from clients.

It's obvious to some of us.... workflow convenience and speed. Imagine I have a page full of images in Publisher and want to make them match better. Using the photo persona, I can quickly open each and make some "tweaks" without adding a huge mess of layers in the Publisher doc. Affinity even made a video about this (some bird photos IIRC). So you can do this with raw files (if they are supported... ahem) , but not officially with jpeg's etc. (There is a workaround however - use Bridge to convert your jpeg, tiffs, etc to DNG. Just be aware that Affinity may read your oddball DNG's white balance incorrectly, but this is easy to adjust. Test it, YMMV.)

OK, tested with Blurb. Passed preflight no problem / no messages. Everything appears to line up (e.g. jacket spine, flaps, etc.) I tried a standard landscape size, with all dimensions specified in points. Bleeds set to 9 points EXCEPT for inner bleed is ZERO. Page size is 684 x 576. Publisher correctly exports pages as 693 x 594. Dust jacket worked correctly too (single page; all bleeds 9 points.) Using Publisher version 1.7.3 for Windows

@Hangman Agreed. PDF format is not the issue here (I only mentioned PDF x3 as that is what Blurb asks for.) Issues are 1) possible rounding error, and 2) bleed handling when exporting as single pages (also asked for by Blurb). On Windows version, if you specify the document using points you will not see a rounding error. You will notice, however, that your width will be out precisely by 9 points (the bleed on ONE side). I see someone else on the forum scrapped setting bleeds and just set a 693 x 594 page size for output. This includes bleeds that will be trimmed assymetrically, so you need to look at your margin settings to make sure everything stays even. Maybe there is an easier way? When I have a chance, I will try a test on Blurb to confirm what the PDF uploader does with this.

As a newbie I am not 100% sure this is correct, but.... It appears that if you setup the document using POINTS (using Blurbs size specifications calculator) then the PDF x/3 export is the correct size. Can someone with more knowledge & experience confirm this please.

Clearly, an Affinity DAM application makes total technical and commercial sense. For me, it's the library / keywording / metadata functions that are most needed. Anyway, Serif have done such a great job so far, the least we can do is be patient and encouraging. I will limp along with good ol' Bridge for now.

AFAIK, It has been identified and reported as a bug. There is another thread here somewhere... Hoping for a quick fix.

haha.... "you don't know what you don't know." Yes, your method works, even in CS6. Anyway, Affinity have an example to copy now. Thanks!