kinvermark
-
Posts
19 -
Joined
-
Last visited
Posts posted by kinvermark
-
-
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.
-
1 hour ago, R C-R said:
I did that because you mentioned bringing a DNG file into AP 2 as a linked file.
How can you link a JPEG file into AP? Have you tried doing that?
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.
-
3 hours ago, Ron P. said:
I agree with @Old Bruce, there's nothing in the Develop Persona that is not already available for non-raw files in the Photo Persona. All the Adjustment Layers and Live Filter Layers have built in masks, and until you remove them, merge them, they're always available for changing later on. You will get nothing different in the Develop Persona.
What worries me, if we push too hard on changes like this, it may cause what we have requested and finally received to break, or start causing bloat. Non-Raw in a Raw Develop app is not reasonable, it's duplication of an already provided feature/function.
My opinion as a photographer, you should be shooting RAW anyway...
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
-
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!
-
The advantage of MAKEGRID is that you can then work with the frames before adding the images. This is more flexible (although as you say slower).
Eg. make a 4 x 6 grid of frames on a full page, then delete all the middle ones. Or a fine grid (say 10 x 20) with some "missing" bricks in the wall. Or change the sizes of certain frames in a unitary way...
-
These are two features I use all the time. Anyone else?
Brief explanation: indesign has a MAKEGRID script that takes a frame object and divides it into multiple frames as specificed by the user (ie rows x columns, gutter, etc.) One can then drag multiple images from the desktop (or DAM eg Bridge) and place them in each of the new frames as wanted.
-
+1. I love Affinity photo, but please do not commit commercial suicide by attempting to bring ANOTHER NLE to market.
There are already dozens at both the professional and non-professional level (Adobe, Avid, Edius, Final Cut, Vegas Pro, Davinci Resolve, Lightworks, Hitfilm, etc.), and they are cheap to buy and in some cases free. Some are decades old and have 100's (1000's ? of programmer years of coding already.) It is technically challenging both to make and support, and the level of user expertise required is quite high.
If forum members need convincing, I suggest downloading DaVinci Resolve (free) and taking a good look at it. Read some forum posts. Still think Affinity should compete with this?
-
Great videos and a great beta. However, James, to state 'you will find that both the interface and functionality translate to the Windows version'... is misleading - just to be clear - several features in MAC are not available in Windows version.. GPS/Location etc..
Hope that helps.
cheers, Paul
Yes, EXPORT LUT appears to be missing from the file menu... I definitely need this. Overall, looks like a great piece of software!
Non-destructive develop persona on Jpg immages in Affinity Photo 2.0
in Affinity on Desktop Questions (macOS and Windows)
Posted
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!