R C-R

You won't need to "connect" to Publisher V2 to do this in the Pixel persona of Affinity Designer but you will need to at least upgrade to Affinity Designer V2 to use the Live Perspective Filter because this feature is in V2 but not V1 of AD. Otherwise, if you have Affinity Photo (V1 or V2) you could open the file in that because it includes the filter.

No, I get a 'file appears to be corrupted' error message.

I meant what tool in AD was doing this, or was selected when you saw the vectors, but I think you already have the answer; namely, that the file of the type you opened already included vector objects. There was no tracing, auto or otherwise, happening in AD.

That is up to you, but keep in mind that the Affinity suite of 3 apps offers much more than just developing RAW files, so it may be worth using them in combination with a RAW developer that does support your camera.

No, while it may be typical, it is not invariably the case that frame text will always use smaller point sizes than art text. But regardless, if there is any use for snapping curves drawn with the Pen Tool to nodes/edges of a selected art text object, then it should be equally useful for frame text objects. And of course, even if the point size(s) of a frame text object is very small, you can still zoom way in to see its snapping candidates, just you like you could with art text. It's just one of the many inconsistencies that occur for certsain Affinity's functions & it needs to be sorted out ... & well documented, too!!!

What does that have to do with the ability to snap to nodes/edges of frame vs. art text objects? If it has any value for one, why not the other?

Any version that explains why it is different for frame text vs. art text would do nicely.

OK, that makes sense, but then why doesn't it also apply to frame text? Aren't users just as likely to want to snap to the same things in frame text when using those snapping options?

What is the "it" that is looking at the frame & not the text in it? If not the Pen Tool then what? It just seems inconsistent & weird that it ever shows nodes (or whatever they are) that can't be manipulated with the selected tool.

OK ... but why doesn't it do the same for Frame Text objects?

Right you are. I should have checked this myself but I just guessed without doing that. Sorry.

The X's indicate the frame is locked. Is it perhaps something on a master page that the currently selected document page includes?

Have you tried duplicating the file in Finder (Mac) or Explorer (Windows) & opening the duplicate (which should have a slightly different filename) in a second tab with the original open?

Can you upload the file so we can see if we can figure out what happened? Also, if the file is still open, what does the History panel show?

I am certainly no expert on such things but from what I can tell from the sample file the vignetting is from the lens not fully covering the sensor or possibly a lens hood that is too narrow. IOW, it is not being filtered in AP, it is just showing what the sensor recorded. Note also that AP may show more of the sensor's output than some other developer apps, including along the edges that are considered not to contain useable image data.

I believe that only applies to importing single layer bitmap files, so I'm not sure what the OP means about AP automatically locking every layer on opening.

What specifically is the "it" that traces some of the parts of the image into vectors? Can you include this AD V2 file or another one showing the same thing in a reply?

Actually, they do something, namely to set the stroke alignment attribute to one of 3 possible values. That they have no visible effect for some vector objects should not be any more surprising than setting the color or cap or join attributes of a stroke when the stroke width is set to zero. For all of them, if or when the shape is closed those attributes become visible in the document view but they are always visible in the Stroke panel or Stroke dropdown in AP, which has no separate Stroke panel. That is simply not true in the Affinity implementation -- the inside/outside/centered attribute is always there, whether or not it has any visible effect. I suppose it would be possible to add an additional set of left/right attribute buttons, but I think it might be confusing if there were two different potentially conflicting results as curves were opened & closed. I don't assume anything other than that the logic is very well established, clearly definable, & completely comprehensible once someone understands its basis. So basically, I do not expect Affinity to do more than explain how it works in for example this Fill Mode help topic for those who do not already know what it does.

On that I completely agree, but the issue here is if there is any reasonable way to make stroke alignment options less ambiguous for all possible operations on vector path objects, & if so what would a way be that would be clear & comprehensible to the greatest number of users. Personally, I do not think there is any obvious solution for this; thus why I think it is a dilemma the developers have not already addressed.

OK, but how specifically do you think they should do that, & do you think there would be any clear consensus for how it should be implemented & labeled? I'm not sure what you mean by this. The results of setting the fill mode of vector paths are completely clear, predictable, & comprehensible if one understands the logic of the Even-Odd & Nonzero rules, & thus why the Fill Mode names are labeled in the UI. The same is not true for the stroke alignment options of vector path objects since there are two possible interpretations of how the results of changing the two non-centered alignments should work whens curves are opened or closed.

So then how do you think they should they be labeled in the tooltips to avoid confusion? Should the names change depending on if the curve is open or closed?

??? So you are suggesting that it just should be a "try one & if that doesn't do what you expect, try the other" kind of option? That strikes me as a terrible idea, about as user unfriendly as it could possibly be. Also, what about the issue I just mentioned about opening/closing curves? What logic do you think should apply there? As for the Fill Mode, it has long been established that the 'winding' determines how this works for self-intersecting vector paths & AFAIK all vector apps use the same convention for its effects.

That I think is the same as the "Left" & "Right" stroke alignment idea, & would work OK (IOW, unambiguously) on paths drawn with the Pen Tool where we have the option to show the curve's direction with the tiny red line, which clearly defines the first & last node of both open & closed curves, but doesn't work for the quick shapes which have no clearly defined direction or first or last node. Also, an open curve can have its stroke alignment set to inside or outside which will become obvious if it is later closed, so it is sort of a 'latent' property & thus should not be greyed out. Likewise, a closed curve can be broken so that property once again becomes latent. So the dilemma for the developers is how to make the stroke align buttons work consistently & logically for all possible path objects that can be stroked.

What do you mean by background color? Are you talking about a fill color or something else?

Why not? If there is no definable inside or outside for certain curve shapes then what would anyone reasonably expect a stroke alignment button named "Inside" or "Outside" to do for those curves? If instead they were named "Left" & "Right" or something similar then that would not work as many would expect for closed shapes. BTW, the fill mode isn't relevant to the stroke alignment so I do not know why you mentioned it.