Image diappears from ressource list

[thadeusz]

- When changing a picture frame to an outline (to change a ractangle picture frame to a freeform frame) the image disappears from the list of placed images. It's just gone.
- I had some jumping in text flow, when changing a picture into a picture frame (containing an image). Text was reflowing incorrectly. When chnaging something in the text body, it somehow came back to it's correct flow.
- Not a real bug, but for me it feels like one: When I change text frame scaling behavior to none, please make it none. Why is it moving the image, when I change the text frame's height or width? I don't get. And suddenly, after some rescaling of the image inside the picture frame it changes it's behavior to what it should be from beginning. Very weird. Please make it consistent and not moving, when selecting none as property.
- and, as we are talking: Please consider a tab "color space" in ressource list. That would make it much easier to find incorrect ones already there.

All Mac Publisher Vers. 1.9.2.

[walt.farrell]

34 minutes ago, thadeusz said:

When changing a picture frame to an outline (to change a ractangle picture frame to a freeform frame) the image disappears from the list of placed images. It's just gone

Can you provide more details of what you did to the picture frame?

[thomaso]

6 hours ago, thadeusz said:

- When changing a picture frame to an outline (to change a ractangle picture frame to a freeform frame) the image disappears from the list of placed images. It's just gone.
(...)
Please consider a tab "color space" in ressource list. That would make it much easier to find incorrect ones already there.

• I don't get issues with converting a picture frame into curves + editing its shape, the image remains in the frame + listed in the resource manager.
• There you also find color space + profile listed in the details section of each single entry. ("find incorrect ones": note, your document's color space can handle others, too, + gives you options how to handle them within .afpub and/or on export)

[thadeusz]

I think I found the problem. It might be possible, that I thought it was already a picture frame and I converted an image's outline from rectangle to curves. That makes more sense, but still it's a bit of a problem. What is the image in this case - a fill and embeded? Anyway - it disappears from the list and I can't make changes to it and I don't know it's resolution and color space. I know, it's my fault, but still can happen. Why can I do this anyway, what is it good for? It should be a picture frame automaticly, when converted to curves. And therfore the image should stay in the list. 

[thomaso]

40 minutes ago, thadeusz said:

It might be possible,

Please try again, avoid guessing.
It works like this: The image gets rasterized and becomes a fill. The options of such a bitmap fill can be set with the Fill Tool.
A fill image can't be linked but you can load another image to replace a current fill image.

 

[thadeusz]

I'm not guessing. You just show, what I've described. Problem stays the same -  and that's what this place here is for. To report and problems and possible bugs.
I don't see a reason and use case, why an image should become a fill and you cannot see anymore, which resolution and color space it has. It totally disappears from ressource list. Why?
Of course I also can see this as a structural problem, where a program should be more than just a typesetting program to collect referenced items and behaves maybe like an image editor. I think it's a problem, when you convert an image accidentally and there is no way back. Which means, you don't know anything about this image and can't change it's parameters in a controlled way. I'd rather prefer, it would in this case be transformed into a picture frame. All would be fine. 

[walt.farrell]

1 hour ago, thadeusz said:

I don't see a reason and use case, why an image should become a fill and you cannot see anymore, which resolution and color space it has. It totally disappears from ressource list. Why?

It disappears because when you convert it to a curve it's no longer an image. The images in the Resource Manager are embedded or linked images (or documents). Once you rasterize them they are not embedded or linked any more, and so it is correct for them to disappear.

[thomaso]

2 hours ago, thadeusz said:

that's what this place here is for. To report and problems and possible bugs.

This is the forum for bugs, there is a separate forum for feedback and one for questions. – Not every unexpected behavior is a bug in terms of programming. Though there is a flowing transition between buggy and unexpected behavior the major difference is the intention of the code, respectively of its initial concept.

Offenbar gibt es für bugs bzw. die Programmierfehlersuche sogar eine Norm, was meine deutsche Seele erstaunt und quasi auch beruhigt. Schwerer nachvollziehbar ist im Deutschen die übliche Formulierung "by design", die einen bug vom nur unerwarteten Verhalten unterscheidet. "By Design" bezeichnet dabei alles was zwar unerwartet sein kann/darf aber nicht fehlerhaft sondern als solches geplant/konzeptioniert/beabsichtigt ist.

2 hours ago, thadeusz said:

I don't see a reason and use case, why an image should become a fill and you cannot see anymore, which resolution and color space it has. It totally disappears from ressource list. Why?

Use case: you want to fill an object with a pattern. This feature enables you to create such pattern easily with a kind of automatism – instead of duplicating or editing such a fill in details manually.

Color space: usually all objects within an .afpub use the same color space set for the document. This feature makes it easier not to need to care for color spaces of placed items.

Resolution: a bitmap (image) fill is useful only in relatively small sizes of the image, e.g. 20% and less. In such cases a usual image resolution of min. 72 dpi will be sufficient because downsizing the image within the fill does increase its resolution accordingly.
Compare: Vector & Texture Brushes in AD / APh, which also use an initially high resolution image as rasterized bitmap and don't offer or require control of the texture's DPI.

2 hours ago, thadeusz said:

I think it's a problem, when you convert an image accidentally and there is no way back.

There are very rare tasks within Affinity with no way back (those display an extra warning dialog).
Almost all actions are 'undoable', either directly after use or at a later moment via the history panel, which offers "branches" for additional undo options. The Help says:

Ich bin sicher, du wirst dieses unerwartete Verhalten nicht mehr oft erleben, denn du lernst automatisch, es vermeiden zu wollen und stattdessen die alternativen, extra dafür geschaffenen Möglichkeiten für verlinkte Bilder innerhalb individueller Kurven-Formen zu verwenden. Neben den Menus liefert vor allem die Ebene-Palette dazu die nötigen Features und unterstützt dich dort zusätzlich mit visuellen Indikatoren. z.B.:

[thadeusz]

15 minutes ago, walt.farrell said:

It disappears because when you convert it to a curve it's no longer an image. The images in the Resource Manager are embedded or linked images (or documents). Once you rasterize them they are not embedded or linked any more, and so it is correct for them to disappear.

Come on, Walt, an image can't just disappear. In the end it's embedded. But you, of course, declare it to be gone. I mean, there might be a reason, why it's not working like that in InDesigen, right?
I wrote about it already that it's a matter of concept here. Affinity has a document format which is ok with embedded, linked, rasterized and vector content and is also meant to ease out these differences between these formats for us. Mostly it's done in a good way. But I really think, there should be at least a warning and I would hope there would be a preference that makes it possible, to not rasterize, but convert to an image frame instead.

Guys, maybe you are right, that it's not a bug by definition, but it felt like one to me. It's definetly a strange behaviour, which should be changed.

[walt.farrell]

15 minutes ago, thadeusz said:

Guys, maybe you are right, that it's not a bug by definition, but it felt like one to me. It's definetly a strange behaviour, which should be changed.

If you don't like what happens when you convert an Embedded or Linked image to Curves, don't convert it.

The behavior is reasonable, and useful in some workflows, even if not for you.

[thadeusz]

Look, Walt, for you version 1.0 of Publisher was already perfect. I get it. I don't know, if you really try to work with it and may find some behaviours strange.
I thought, it's important to write about these things, so other users might find it and can work around it. Also discussing, how users are approching certain funcions is crusial to improve these programs. It's a strange attitude, if it's at the end always just about saying it's your fault, if you don't like it. Whatever..

[thomaso]

58 minutes ago, thadeusz said:

It's definetly a strange behaviour, which should be changed.

As pointed out above in various ways this behavior has useful reasons. So your "definitely" and "should" sound neither necessary nor useful, especially if you consider to make use of the additional option for assigning keyboard shortcuts for your preferred kinds of conversion. Can't be easier & faster then to use only the desired, expected function.

21 minutes ago, thadeusz said:

I thought, it's important to write about these things, so other users might find it and can work around it. Also discussing, how users are approching certain funcions is crusial to improve these programs.

Also mentioned above there are two forums to discuss such ideas. I definitely think you should use them instead of this bugs forum and additionally increase the chance that other users might find your thoughts. You might notice that the according forums are read / used more frequently – in particular to discuss impressions / feelings like yours in this case.

[thadeusz]

Ok, back to the problem. Let's just have a look from a more basic position. I'm in Publisher (not in photo or designer or their personas). I'm positioning an image and it doesn't have a picture frame. Why does it say "convert to curves"? I think, this is misleading, as this term is to my knowlegde used for vectors which are transformed from a reactangle (or other basic shapes) to a curve. Instead it should say "rasterize" or at least warn me if I misunderstood. If my image has an image frame, all is fine and working as expected. I know, and thank you for this perspective on it, that this is not neccesarly a bug. But for me, it's also not a strange function, but working incorrectly. I think, it's ok for me to stay here with my comment and report it as a bug.

[thomaso]

1 hour ago, thadeusz said:

I think, it's ok for me to stay here with my comment

In case you haven't noticed: meanwhile this topic has moved to the feedback forum, here any discussion fits. Though even here it's useful not to mix various subjects unless you don't mind. Subjects in separate topics are more obvious to the community because of their separate titles in the thread list view.

1 hour ago, thadeusz said:

I'm positioning an image and it doesn't have a picture frame. Why does it say "convert to curves"? I think, this is misleading, as this term is to my knowlegde used for vectors which are transformed from a reactangle (or other basic shapes) to a curve. Instead it should say "rasterize" or at least warn me if I misunderstood.

I am sorry, I haven't been precise in this previous post. Actually by "convert to curves" an image gets converted to curves (with editable vector shape) but not rasterized. This way its resolution is maintained and can be fully used in a possible pattern or still increased without loss according to its original resolution.

If you do an action which requires rasterization (e.g. applying a filter in APub's photo persona) then the app does warn you with a temporary assistant message in the upper right corner. (by the way: there is a feature request for a longer duration of this popup)

The Layers panel indicates various types with its label texts in round brackets. Curve vs. Pixel: While converting to curve doesn't change/influence the image resolution, rasterizing "burns" (fixes) its resolution according to its current size in that moment, so for rasterizing the current object dimensions + document resolution are relevant. When up-scaled after applying the command they may appear in different resolution (depending on their dimension at the moment of the command).

 

[thadeusz]

Of course I also had to think about the different behaviour of pixel (rasterized) versus image layer in Photo. And why it's ok for me there. First, working with pixels forces you to have more an eye on resolution. Very often I switch to 100% pixel view to get an idea, if the resolution of a an image (or part) is matching and holding up within a montage. But maybe It would be even here good to know, what the original resolution compared to a montage actually is (as long as it is not rasterized).  

Normally when producing a book I'd have an eye more on the placed resolution of images and their color space. Working on images is done separately, which doesn't mean earlier. So it's more of a collecting and a layout process. To know parameters here is crusial. Maybe this old school approach will change over time with new concepts coming in. So for me part of this problem here is, that serif is mixing up different concepts and is not very strict in separating them from each other. And to be honest, I'm not very confident, that they are very good in developing new ways of fast and fluid workflows (but still hope for it). Most new are ideas are half-baked (as mentioned: strange/inconsitent image scaling properties inside image frame - WTF? - but it looks great in the videos).

By the way - when rasterizing the so called curve layer of my unintentionally (not rasterized) image - the resolution shows up again in the left upper corner. Why not before rasterizing? And why can't I switch back to image frame, when I worked on the outline? It really makes no sense in the Publisher area..
 

[thomaso]

Instead of asking only
"Why don't they make the interface like I expect it?"

one could also question
"WTF let me expect it different than it is?"

[thadeusz]

Wow, what an answer. Sorry, that you had to read a longer text which is not fitting your own opinion. Maybe I shorten this next time for you. How could I think this would be a good place to exchange opinions and perspectives. And sorry for disturbing you guys living around here. I would hope to have a possibility for bug reports without actually discussing if it is a bug or not. I'm off..

[loukash]

5 hours ago, thadeusz said:

when rasterizing the so called curve layer of my unintentionally (not rasterized) image - the resolution shows up again in the left upper corner. Why not before rasterizing?

That's a good question.
It would be good to see what the original resolution of a bitmap fill was. Especially since there doesn't seem to be an option to reset to its original dimensions, only to original proportions.

For what it's worth though, to recap:

• if you convert a placed image to "Curves", its bounding box becomes a vector shape (usually a rectangle), and the image becomes a fill of type "Bitmap"
• the conversion is destructive, so to revert, you either undo or you place the external image again
• to "fine tune" the bitmap fill and make use of all its available options, select the object with the Fill tool and check out the context toolbar as well as the context infobar at the bottom of the document window
• the vector curve outline can be edited like any other vector object, changing its shape as you see fit
• to see what will happen to the bitmap fill on export/print, enable View > View Mode > Split View which is your pixel preview based on File > Document Setup > DPI

Hope that helps.

[thomaso]

4 hours ago, loukash said:

9 hours ago, thadeusz said:

when rasterizing the so called curve layer of my unintentionally (not rasterized) image - the resolution shows up again in the left upper corner. Why not before rasterizing?

That's a good question.
It would be good to see what the original resolution of a bitmap fill was. Especially since there doesn't seem to be an option to reset to its original dimensions, only to original proportions.

Though I would not mind to see the info I doubt it would be really useful (~ necessary) in practical use. As mentioned above, considering that a bitmap fill gets mainly used as pattern it is therefore downscaled, hardly increased. The various options like repeat (~stretch), mirror etc. do imply that the initial image doesn't appear in its original size and also there are options for interpolation to reduce possible jagging. Also note that there is no option for distance when wrap or mirror is used, that means you would prepare such a resource especially for this use (e.g. add a white margin) and would set its size accordingly, well knowing it will be used in smaller size. So, in case you want to achieve a specific result (different to just experimenting) I guess you would need to do some calculation anyway before using a bitmap fill.

[fde101]

9 hours ago, thadeusz said:

when rasterizing the so called curve layer of my unintentionally (not rasterized) image - the resolution shows up again in the left upper corner. Why not before rasterizing?

Because the curve is vector and thus has no resolution.

Once you rasterize it, it becomes raster and has a resolution which can be displayed.

 

The selected object in this case is not the fill being used for the vector curve, but the curve itself.

[thomaso]

38 minutes ago, fde101 said:

Because the curve is vector and thus has no resolution.

The question was related to the curve's content, the image, converted to a bitmap fill.
The curve can be edited separately from its content, so curve & fill are two different things, the bitmap is hardly the curve itself.

[loukash]

7 hours ago, thomaso said:

I doubt it would be really useful (~ necessary) in practical use

That's irrelevant.
The original and current resolution value is still stored there somewhere for sure, much like with any placed image. It's just not being displayed in this context.
I can't think of an argument why not to display it, much like I can't think of an argument that we should not be able to reset a bitmap fill back to its initial resolution.
Those two options are simply not there.
That's an omission – if not to say a flaw – and not a "feature".

I haven't had any practical use for this mode yet, but after playing with it last night, it feels rather half-baked to me. You can only adjust parameters visually, not by numbers. When you mess up, you may need to revert everything and start over again. It's a gimmick, as far as I'm concerned…

(edit: we're getting slightly off topic though… )

Edited April 10, 2021 by loukash

[fde101]

8 hours ago, thomaso said:

The question was related to the curve's content, the image, converted to a bitmap fill.

The question I was responding to was why the resolution was not showing up in the context bar when the curve layer was selected.

A bitmap fill is not a layer and cannot be selected.  @thadeusz had selected a vector object and was looking for raster information in a part of the interface which takes its context from the selected layer (the curve, not the fill).

Whether or not the attempt was to find resolution information for the fill, that is not the point as it is not how the application "thinks".  It is showing context for the selected layer, not for its fill.

 

Having access to that information for a bitmap fill is not a bad idea (it is in fact a quite good one), but with most tools, that is the wrong place to be looking for it, as further cluttering the context bar with that kind of detail does not seem remotely appropriate.

There is an exception, though: the fill tool (gradient tool in Photo) is designed to control the properties of the fill or stroke.  Adding resolution information about a bitmap fill to the context bar for the fill tool when a bitmap fill is present would seem entirely appropriate and the context bar for that particular tool has plenty of space available right now where it could be added.

Alternatively, the idea of adding bitmap fills to resource manager and making that information available there is not a bad one either.

[loukash]

44 minutes ago, fde101 said:

Adding resolution information about a bitmap fill to the context bar for the fill tool when a bitmap fill is present would seem entirely appropriate and the context bar for that particular tool has plenty of space available right now where it could be added.

Yep.

44 minutes ago, fde101 said:

Alternatively, the idea of adding bitmap fills to resource manager and making that information available there is not a bad one either.

Double-yep, a.k.a. yepyep.

[thomaso]

1 hour ago, fde101 said:

Whether or not the attempt was to find resolution information for the fill, that is not the point as it is not how the application "thinks".  It is showing context for the selected layer, not for its fill.

Just a note to «how the application "thinks"»: The app currently is willing & able to handle, report + give access to various kinds of content of a selected layer: An image layer does get its pixel resolution AND its vector stoke properties reported.

From that perspective the thinking of the app appears oddly limited once the border of such a layer gets converted to an editable shape, as if the thinking would lack in multi-tasking. So it's hardly comprehensible that "Convert to Curves" interrupts access to the existing image information.