Neue Testversion 18.40b12

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

PPI, DPI -- Oh, my!

Post by photoken »

I think it's meaningless and absurd to consider PPI (or DPI) when editing an image. Image editing software modifies individual pixels, and a pixel is a pixel is a pixel. Period. "Pixel", in other words is a non-scalar unit.

It's only when an image (either on its own or as an item in a document) is output to a printer that converting pixels to a dimension becomes important; and, in that case, you're telling the printer to scale the whole darned thing to a particular paper size, and how fine a resolution the printer should use for its output.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 18.40b12

Post by Herbert123 »

bkh wrote: Generally, PL respects ppi settings in document mode. However, this changes when the image doesn't fit the document borders – in that case, the image is scaled to fit. I've also had cases where this was undesirable (and worked around it by using a large enough document and by setting the correct document size only after the import, but I wouldn't mind if Document Mode always respected the images' ppi values. (Presumably, the reason behind PL's current behaviour is that many images these days, especially from cameras, have arbitrary ppi settings.)
Yes, at least an option somewhere to control or select this behaviour would be very welcome. For example: 100% doc size / true pixel (disregarding ppi altogether, and just use 1-1 pixels / respect placed image ppi.
bkh wrote: Currently, PL shows the calculated ppi in the Attributes panel. You are right, the native resolution might be useful as well.
Yes, I agree - perhaps in the format "141 [300]" when the dpi differs from the original one, and otherwise just "300".
bkh wrote: Works here, just change the value in the Attributes panel.
Darn, I somehow completely overlooked that option! And I used it before even! Thanks!
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 18.40b12

Post by Herbert123 »

Martin Huber wrote:
Herbert123 wrote:5) Photoline uses "dpi" everywhere when it really means "ppi". It's a common mistake - when talking about resolution of images while working on a screen, "ppi" is the correct term. When talking about a print on paper or the output quality for a particular print device, "dpi" is used.
I see no reason for differentiating between "dpi" and "ppi":
- Most people use "dpi".
- A pixel is a dot, too.
- There is no intersection between the fields of application of "dpI" and "ppi", so there is no risk of a misunderstanding.
- The producers of flatbed scanners state the resolution in dpi, too, and they don't scan "dots" but "pixels" (which is in my opinion the same).

Martin
True, it is not that important anyway.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 18.40b12

Post by Herbert123 »

Martin Huber wrote: In the past we always respected the dpi value, but we changed that because of user complaints. As you said yourself many files have arbitrary dpis, but there are also a lot of files with nonsense dpis, for example megapixel images with dpi values of 1.
It would be extremely useful to have options in the place holder tool settings to control the scaling: a dropdown for "true pixel resolution" and "respect file dpi". The first option is essential for web, game, and screen work (you want the pixels to match up with the one for the document), and the second option for print layouts (this behaviour is standard in every single other dtp related application).

A third option "Default" would import the file according to the current implementation.
Martin Huber wrote: Is there a common situation, where it is useful to show the native dpi? You have to keep in mind, that each additional line in the Layer Attributes makes them less useful. I am still asking myself whether the overprint settings are so important to show them in the Layer Attributes.

Martin
You could solve it this way: "43dpi [300dpi]" in the Resolution attribute when they differ, and otherwise if they match up just show the one.

This way we can tell if an imported image's dpi is different from its true dpi. Then we can change it manually to 300 in this example. Otherwise we would have to open the file seperately and check the dpi parameter. That is what I do now to solve this in Photoline.

Another reason why we would want to know this true ppi, is that it will tell us at a glance whether our layer has enough resolution to be printed at a sufficient quality. "43dpi [300dpi]" immediately warns us that the layer has much to low resolution for a quality print. Otherwise we are left guessing, and in the worst scenario we would send off a file to the printer with an end result that the print looks extremely fuzzy.

As for the overprint settings: you mentioned before that these only work in CMYK mode anyway - why not hide them when the user is working in a different mode? They are only relevant for CMYK - in that case they do become important to display (in my opinion).
Last edited by Herbert123 on Fri 13 Jun 2014 09:16, edited 1 time in total.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 18.40b12

Post by Herbert123 »

By the way, Martin, have you considered the inclusion of a color reduction adjustment layer with similar functionality as the overall save for web options? It would make it a thousand times more powerful for screen, web, and game work - especially when combined with the current layer export! (Aside from certain artistic possibilities that such an adjustment layer would offer us :) )

I recall having this discussion with you about how Photoshop uses Generator that requires obscure layer name codes to export layers with a specific resolution/color reduction/file format. A color reduction adjustment layer in combination with the layer export would solve this quite elegantly.

Photoline's web/screen graphics export would be modernized in one fell swoop. It would be an awesome addition - something no other image editing software offers at this time. It would also make Photoline an extremely attractive proposition for web/mobile devs and designers.

Cheers!
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: PPI, DPI -- Oh, my!

Post by Herbert123 »

photoken wrote:I think it's meaningless and absurd to consider PPI (or DPI) when editing an image. Image editing software modifies individual pixels, and a pixel is a pixel is a pixel. Period. "Pixel", in other words is a non-scalar unit.

It's only when an image (either on its own or as an item in a document) is output to a printer that converting pixels to a dimension becomes important; and, in that case, you're telling the printer to scale the whole darned thing to a particular paper size, and how fine a resolution the printer should use for its output.
True in some cases, and in other cases it does become very important to consider the ppi of an image before you start working. In Photoline's document mode dpi is an important factor to take into consideration.

One such example would be when you have to prepare artwork for a specific print job - let's say a comic or an illustration with both coloured and b&w artwork: in that case I want a higher resolution ~800ppi b&w monochrome layer, and underneath a 300ppi colour layer - in the same file.

Also, don't forget that some of the most basic rules in regards to pixels are turned upside down since the advent of retina-like displays (iPads, iPhones, Samsung tab, retina notebook displays, etc) where currently a square of four pixels is interpreted as one pixel. So it is no longer as clear-cut a situation as it used to be only a couple of years ago.

When I prepare artwork for a responsive website in PL, I need to prepare graphics at two resolutions now: one for the classic display resolutions, and one for retina screens that doubles the required resolution, but still displays at the same scale as the lower resolution one.

Somewhat inconvenient, but in these cases a pixel is no longer "just" a pixel. It depends on the device and display dimensions how they are interpreted.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: PPI, DPI -- Oh, my!

Post by photoken »

Herbert123 wrote:One such example would be when you have to prepare artwork for a specific print job - let's say a comic or an illustration with both coloured and b&w artwork: in that case I want a higher resolution ~800ppi b&w monochrome layer, and underneath a 300ppi colour layer - in the same file.
Not to be argumentative, but I'm just curious why you need to do that. I assume the B&W layer is the line art and the colour layer is, well, the colouring.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: PPI, DPI -- Oh, my!

Post by photoken »

Herbert123 wrote: Somewhat inconvenient, but in these cases a pixel is no longer "just" a pixel. It depends on the device and display dimensions how they are interpreted.
I disagree. An image pixel is still just an image pixel. What a screen or printer does with the incoming pixels is its problem. In other words, you tell the screen or printer to do whatever it takes to make the incoming image occupy x% by y% of its output size.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: PPI, DPI -- Oh, my!

Post by Herbert123 »

photoken wrote:
Herbert123 wrote:One such example would be when you have to prepare artwork for a specific print job - let's say a comic or an illustration with both coloured and b&w artwork: in that case I want a higher resolution ~800ppi b&w monochrome layer, and underneath a 300ppi colour layer - in the same file.
Not to be argumentative, but I'm just curious why you need to do that. I assume the B&W layer is the line art and the colour layer is, well, the colouring.
Because the B&W line art can be printed at a much higher resolution.

I am not sure how deep your prepress knowledge reaches, but have you ever used a magnifying glass to examine printed matter? Most continuous tone colour work is prepared at 300ppi. When colours are printed, any colour other than cyan, magenta, and yellow has to be simulated by create a halftone dot raster and combining cmyk plates using dot patterns - which means the offset machine or digital print hardware (or other print hardware) operates at much higher effective resolutions (around 2500dpi on average I believe), but this resolution is lost when the halftone rasters are created to simulate full colour.

This is of course not true for regular body text. Text is printed in b&w (as are b&w vectors), and can be theoretically printed at the max resolution of the print hardware used for your print job. But in practice the real achievable maximum print resolution for b&w (or for true magenta, yellow, cyan, hexachrome, or spot colours) is limited by the paper you print on.

A good quality colour magazine, coffee table book or comic printed on glossy paper can reach a higher quality print resolution on paper than, let's say, vellum stock paper/newspaper paper. This has to do with the amount of ink coverage various kinds of paper can tolerate. So on average 1200dpi is the max for text and (vector) line art, and often lower.

Now, we can also create our own high resolution black and white artwork, and print that at the same much higher effective resolution than colour work. So for comic books on glossy paper stock we can go as far as 800ppi in practice. Academic print houses generally ask for 1200ppi black&white line artwork. For colour 300ppi suffices. Remember, these are "safe" numbers - if you need to be sure, ask your printer.

For photos different rules may apply - for example, a photo printed as a duotone, or even as a tri-tone, can be visually of a much higher quality than a simple greyscale print - extending the photo's range of contrast and hues on paper. Different (higher) ppi resolutions may be required for these type of prints.

So that is why I want my illustrations' colour layer(s) prepared at 300ppi (or higher - I tend to go with 600ppi to be able to print potentially at higher resolutions later), and the b&w artwork at 1200ppi (or higher again if I expect it to be printed at greater dimensions later). This way I get the ultimate quality line print quality versus a great colour reproduction. Comics are often printed like that - in two layers: one for colour (at least 300dpi), one for the line work (at least 600ppi).

If you already knew about these things, my apologies. This is just the basics, actually. When in doubt confer with your printer!
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: PPI, DPI -- Oh, my!

Post by Herbert123 »

photoken wrote:
Herbert123 wrote: Somewhat inconvenient, but in these cases a pixel is no longer "just" a pixel. It depends on the device and display dimensions how they are interpreted.
I disagree. An image pixel is still just an image pixel. What a screen or printer does with the incoming pixels is its problem. In other words, you tell the screen or printer to do whatever it takes to make the incoming image occupy x% by y% of its output size.
Well, we could argue for the sake of the argument about this - in principle a pixel is composed of rgb dots, and there are several tech methods to create pixels.

I completely agree with you that a pixel is just a pixel, and that the device's screen tech and software tells it how to display a pixel.

In practice, depending on the circumstances, on 4k and retina screens a pixel may no longer be treated as one pixel, but as a group of pixels. Sure, an image pixel is still just an image pixel - what has become more important in this discussion is: how is an image interpreted, treated, and scaled in relation to its native true pixel resolution?

That is what I meant with my words. Pixels are still discrete elements, but with the new screens achieving ever higher resolutions at varying display dimensions, my experience tells me we can no longer always treat a pixel as a discrete element in our work: practically, screen technology has advanced to the point that thinking in mere pixels is not enough anymore. Which is why a lot of developers and designers are looking at vector graphics as an alternative for bitmap images for screen work.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
Martin Huber
Entwickler
Entwickler
Posts: 4004
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 18.40b12

Post by Martin Huber »

Herbert123 wrote:It would be extremely useful to have options in the place holder tool settings to control the scaling: a dropdown for "true pixel resolution" and "respect file dpi". The first option is essential for web, game, and screen work (you want the pixels to match up with the one for the document), and the second option for print layouts (this behaviour is standard in every single other dtp related application).
Placeholders currently don't show the resulting dpi (in contrast to images which do). It might be useful to show the dpi with placeholders, too, if the placed file is a simple image.
Herbert123 wrote:You could solve it this way: "43dpi [300dpi]" in the Resolution attribute when they differ, and otherwise if they match up just show the one.

This way we can tell if an imported image's dpi is different from its true dpi. Then we can change it manually to 300 in this example. Otherwise we would have to open the file seperately and check the dpi parameter. That is what I do now to solve this in Photoline.
Why would I want to check the original dpi? Isn't the only interesting fact the resulting resolution? If I know, that I need 300 dpi for colored images and 1200 dpi for b/w in order to print correctly, why should I be interested, whether the color file had a resolution of x dpi or the b/w file a resolution of y dpi?
Herbert123 wrote:As for the overprint settings: you mentioned before that these only work in CMYK mode anyway - why not hide them when the user is working in a different mode? They are only relevant for CMYK - in that case they do become important to display (in my opinion).
Overprinting works always with spot colors, it might work with CMYK - depending on the layer content and the PDF export options. So in order to use overprinting you have to know the overprinting rules, or you are doomed to fail. If PhotoLine sometimes shows overprint settings and sometimes not, it might give the user the impression, that PhotoLine will take care of the overprint problems, while it does not and cannot.

Martin
Martin Huber
Entwickler
Entwickler
Posts: 4004
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 18.40b12

Post by Martin Huber »

Herbert123 wrote:By the way, Martin, have you considered the inclusion of a color reduction adjustment layer with similar functionality as the overall save for web options? It would make it a thousand times more powerful for screen, web, and game work - especially when combined with the current layer export! (Aside from certain artistic possibilities that such an adjustment layer would offer us :) )
I understand the artistic possibilities of an color reduction adjustment, but I don't think, it is useful as extension of the export options.

Color reduction as adjustment layer would be restricted compared to the normal color reduction function, because adjustments have to be fast and have to be able to work correctly with only parts of the document. This means, that a color reduction adjustment could only work with a fixed color palette (the current "loaded" option of the Reduce Colors) and Nearest Color, or with one of the ordered dither modes. Error diffusion and automatic calculation of color palettes are not possible because of performance reasons.

Martin
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 18.40b12

Post by Herbert123 »

Martin Huber wrote:
Herbert123 wrote:By the way, Martin, have you considered the inclusion of a color reduction adjustment layer with similar functionality as the overall save for web options? It would make it a thousand times more powerful for screen, web, and game work - especially when combined with the current layer export! (Aside from certain artistic possibilities that such an adjustment layer would offer us :) )
I understand the artistic possibilities of an color reduction adjustment, but I don't think, it is useful as extension of the export options.

Color reduction as adjustment layer would be restricted compared to the normal color reduction function, because adjustments have to be fast and have to be able to work correctly with only parts of the document. This means, that a color reduction adjustment could only work with a fixed color palette (the current "loaded" option of the Reduce Colors) and Nearest Color, or with one of the ordered dither modes. Error diffusion and automatic calculation of color palettes are not possible because of performance reasons.

Martin
Thank you for explaining the technical drawbacks of such an adjustment layer. I would just like to see some kind of other solution for tagging layers and layer groups with how they should be optimized in combination with the layer export function. Currently when working with web layout and mobile mockups it is a chore to export all the individual layers and layer groups with the web export function.

This is how it works now:
1) export or copy selected layers in a new document for the component that I want to export
2) open the web export.
3) change the settings for best export quality, and select a file format. Presets can be handy, but often every asset has different quality settings for the best file size/quality balance.
4) preview, and go back to step 3 if color reduction does not work out well.
4) export
5) go back to step 1 for the next asset

It just takes too much time when the user has to deal with many assets in a mockup, and the web export becomes quite a daunting prospect. So some kind of quick layer tagging and adjusting option with a way to preview the effect in the normal view would save a lot of time.

One more question: when I choose PNG, and try to reduce the number of colours to 512 or more colours, PL refuses to accept my choice: it flips back to 256. Is this a bug? I would like to save PNGs with full transparancy and a reduced palette of 512 or more colours for better quality.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: PPI, DPI -- Oh, my!

Post by photoken »

Herbert123 wrote: In practice, depending on the circumstances, on 4k and retina screens a pixel may no longer be treated as one pixel, but as a group of pixels. Sure, an image pixel is still just an image pixel - what has become more important in this discussion is: how is an image interpreted, treated, and scaled in relation to its native true pixel resolution?

That is what I meant with my words. Pixels are still discrete elements, but with the new screens achieving ever higher resolutions at varying display dimensions, my experience tells me we can no longer always treat a pixel as a discrete element in our work: practically, screen technology has advanced to the point that thinking in mere pixels is not enough anymore. Which is why a lot of developers and designers are looking at vector graphics as an alternative for bitmap images for screen work.
A lot of new technology has been introduced since I worked in the production side of the commercial art industry 30 years ago, but the fundamental principles remain the same.

Of course, if your client or service bureau has certain requirements, you must meet those requirements. Often, a client's (or service bureau's) way of doing things is not the only way, or even the best way, however. I don't see the point of the creator specifying different resolutions for different image layers. The output of each layer should be the responsibility of the print shop, to my thinking, but one has to take the world as it is....

A couple of general points:
1. There's no such thing as a "native true pixel resolution" for an image. The image has pixels, which do not have dimensions, and that's that.
2. The distinction between "PPI" and "DPI" is important. "PPI" is a means of specifying the size of the original image as it's displayed on-screen. Think of it as a variation of "scaling". "DPI" refers to the resolution of the image when it's printed. It's the equivalent of "lines per inch" used to describe the half-tone screen used to print an image. DPI determines how accurately the printed image reproduces the contours and tones of the original image. For example, Architectural Digest can afford to use expensive papers, etc., and therefore DPIs of 600 or more. It's printed images are beautiful renderings offering wonderful details and tones. A newspaper publisher, on the other hand, will use a much coarser screen to reproduce images that are "good enough" for the viewer to get a decent impression of the content of the original image.
3. Since pixels are discrete elements (by definition), even given advances in screen technology one still has to think of pixels as pixels. That's just the nature of using raster images. Vector graphics are completely different, of course, and that's why we've been using them for decades. After all, computer fonts are nothing but vector graphics. In fact, I'm surprised that any designer or artist is still using raster images.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
User avatar
Herbert123
Mitglied
Posts: 2047
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 18.40b12

Post by Herbert123 »

I finally was able to find the reason for the redraw bug I am experiencing at times in Photoline. If a vector overshoots its content frame, PL will have issues redrawing the sections that fall outside that box.
Untitled.jpg
I have included a demo file. Try resizing, or rotating the object.
You do not have the required permissions to view the files attached to this post.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait