Neue Testversion 18.90b6

[Herbert123]

Bug: copy and paste vector object in a new file crops the object incorrectly:

crop.png

[Herbert123]

Nasty bug!

When bitmap layers are positioned with a decimal value, and the image is cropped, the image data for the bitmap layers that are positioned to non-decimal non-exact x and y values will be changed. All decimal positions are recalculated to non-decimal ones as well: so 100.5 becomes 100, for example.

estructor.altervista.org/test.pld

After the crop the original bitmap layer's sharpness is no longer available, and the quality is impaired. This does NOT happen to any bitmap layer that was exactly positioned to non-decimal x/y values.

Please crop this example so that the document is nicely cropped, and compare the quality of the exactly positioned bitmap layers with the ones that are placed with decimal positional x/y values. Move the bottom ones to an exact non-decimal pixel coordinate.

Then compare the quality before the crop action, and move the decimal x/y positioned bottom bitmaps to exact pixel precise non-decimal values.

Before the crop, when the bottom ones are placed on exact non-decimal x/y values, the quality is the same as the original top ones. After a crop, this is no longer the case, and Photoline changed the image data for those bottom bitmap layers.

Btw, this is another viable reason why I would like to see pixel snapping to exact values for all layer types implemented in Photoline (see requests thread).

[ellhel]

Einfach mal so......Ich wünsche Euch allen eine geruhsame Zeit und viel Gesundheit.
Auf das wir uns hier noch oft "Begegnen"

Frohe Weihnacht......jpg

Festliche Grüße
Helmut

[Herbert123]

Did something change internally in Photoline in regards to larger files? Because I cannot open a psb or pld file that is 10gb in file size, and about 70.0000 by 50.0000 pixels.

It has been a while since I had to open these files, and Photoline now cops out with an error "Problem while loading". Even a 25000x26000 pld that I saved a year ago will not open, and throws the same error.

[Martin Huber]

Nasty bug!

When bitmap layers are positioned with a decimal value, and the image is cropped, the image data for the bitmap layers that are positioned to non-decimal non-exact x and y values will be changed. All decimal positions are recalculated to non-decimal ones as well: so 100.5 becomes 100, for example.

That is not a bug. If an image layer has to be cropped to the document bounds, it must be rendered, so that its pixels are aligned to the document pixels. There is only one alternative: not cropping or only partly cropping those layers. This is what happens in document mode.

Martin

[Martin Huber]

Did something change internally in Photoline in regards to larger files? Because I cannot open a psb or pld file that is 10gb in file size, and about 70.0000 by 50.0000 pixels.

It has been a while since I had to open these files, and Photoline now cops out with an error "Problem while loading". Even a 25000x26000 pld that I saved a year ago will not open, and throws the same error.

I don't know a change in this regard.
I just tried a simple 50000x50000 document and there was no problem. What's the content of your documents? Large pixel images?

Martin

[Herbert123]

Nasty bug!

When bitmap layers are positioned with a decimal value, and the image is cropped, the image data for the bitmap layers that are positioned to non-decimal non-exact x and y values will be changed. All decimal positions are recalculated to non-decimal ones as well: so 100.5 becomes 100, for example.

That is not a bug. If an image layer has to be cropped to the document bounds, it must be rendered, so that its pixels are aligned to the document pixels. There is only one alternative: not cropping or only partly cropping those layers. This is what happens in document mode.

Martin

Thanks, switching to document mode prevents the re-rendering of the layers. I hope you will consider implementing pixel snapping with no decimals in the position and scaling for all layer types at some point - it would make life in PL much easier for pixel precise layouts.

Speaking for myself here, I have to enter exact positional values for each and every bitmap manually almost every time I move a bitmap and text layer, as well as for the guides, when I use PL for web/screen/mobile work. As you can imagine, It's a lot of additional work, and error prone.

This also still holds true for vector layers, even with pixel snapping turned on. Because the actual x and y positions still display with a decimal, I have to make certain the x and y positions, as well as the dimensions, are correct due to how PL decides to place the strokes.

For example, when a vector rectangle (height 21.4px) is positioned at x:550.8px and y:148.9px, PL will position that vector rectangle at x:550 and y:148px. with a height of 23px. But with y:148.1px that same rectangle suddenly has a height of 22px. So to make certain the values all add up correctly I must set both the position and scale values to exact non-decimal pixel values, otherwise I cannot predict what is going to be the result.

Then there is still the problem that when a rectangle is drawn at an exact x:550px and y:148px position, the actual top and left stroke will be drawn visually at x:549px and y:147px (rounded down for some reason). So even when I carefully place exact guides at x:550px and y:148px, and snap a vector rectangle at that x coordinate, the stroke will be drawn at x:449px and y:147px instead !!!

So I wind up checking every guide, layer, etc. to see if they align properly for pixel precise layouts. This includes all the bitmap layers, vector layers, and text layers! It is an extremely time-consuming process, and certainly something I would like to see solved - it makes Photoline a tough proposition for this type of work. And Photoline is a pixel manipulation application, is it not?

I understand that these are difficult problems to solve. But there is already a good example of how to deal with these problems: Adobe Fireworks, which is no longer developed, but still runs circles around applications like Photoline and Photoshop in regards to how it works with pixel precise layouts.

Proposed solution(s):

1) with document/layer pixel snapping activated, all layer types (not only vector layers) will snap to exact pixel coordinates. No more decimal values. Perhaps an additional requirement would be to switch first to pixel units for the rulers as well. This also prevents the issue that sharp edged bitmap artwork are blurry looking, and text is rendered with varying anti-aliasing.

2) when document/layer pixel snapping is activated, non-decimal values are always rounded up or down in the numeric input fields. Moving and scaling a layer always works with exact pixels: no more decimal values. This will also make Photoline's behaviour far more predictable.

3) an option to draw strokes on the outside, inside, and center of any vector edge. Refer to Fireworks for this solution (see below).

4) when working with pixel snapping turned on for the document, and rulers set to pixels, guides should always snap to exact pixel coordinates. No more decimal values in this case. Ideally this should also work for the new guide creator.

5) when pixel snapping is activated, and the rulers are set to pixels, moving layers with the cursor keys will move those by exactly 1 pixel. ctrl-cursor keys will move by 10 pixels.

6) when pixel snapping is activated, for the inside and outside stroke placement, straight lines should ideally not be anti-aliased (see example below)

Visual reference how stroke placement should work (and this is also great for non-pixel precise work, by the way). All rectangles are snapped exactly to the guides.

Untitled.png

I really hope and pray some of the suggestions will be implemented.

[photoken]

3) an option to draw strokes on the outside, inside, and center of any vector edge.

I agree. This has been a long-standing request of mine.

The same options for inside, outside and centered should also be available for the Border Mask function.

[Hoogo]

Idea: Could the channels be added to the dropdown in the magnifier panel? I imagine that it will make it much more easy to check single channels.

Find the latest pictures of wrong menu titles attached. I don't see any logic anymore. I'll restart the PC now. Place your bets, I say that this will solve the problem for a while .

I also found some wrong heights of menu entries, but they were only slightly off, just a little narrow. But shouldn't there be some kind of log file?

EDIT: Restart did really help! What about the others with this problem? When I shut my Laptop or leave my PC, it just goes to "Energie sparen", not "Ruhezustand" or even "Herunterfahren" (don't know how these modes are called in an English WIndows). I guess the problem will return in a few days.

[Hoogo]

4.11 The Layer Attributes

The description of the vector attribute is something totally different than the available attribute.
"Overprint" is not explained.

[Martin Huber]

Find the latest pictures of wrong menu titles attached. I don't see any logic anymore. I'll restart the PC now. Place your bets, I say that this will solve the problem for a while .

I also found some wrong heights of menu entries, but they were only slightly off, just a little narrow. But shouldn't there be some kind of log file?

I don't think, we still create the log files, because we know why the problem occurs: for some unknown reason Windows doesn't ask PhotoLine for the size of some of its menu entries. While that's a minor problem with the height of menu entries, it is a major problem with the width of menu titles.

EDIT: Restart did really help! What about the others with this problem? When I shut my Laptop or leave my PC, it just goes to "Energie sparen", not "Ruhezustand" or even "Herunterfahren" (don't know how these modes are called in an English WIndows). I guess the problem will return in a few days.

Please keep us informed whether the error returns and whether a new reboot "fixes" it again.

Martin