Resolution for an adjustment layer?

[asharpe]

I've been ignoring the fact that my adjustment layers (curves, gray mixer, unsharp masking, etc.) have 72 dpi resolution, and simply change the document's resolution to 300 dpi after I flatten the layers before I write out to a tiff file. This seems to be fine, but I guess I don't understand what impact the resolution of an adjustment layer is. Will it make a difference during my editing if I make all the adjustment layers 300 dpi?

And what about 16 bit, instead of 8 bit for adjustment layers? I'm trying to keep a full 16 bit workflow, and the 8 bit layers bother me a bit, but I haven't seen any apparent differences in the on-screen or printed images when I change these layer parameters.

[photoken]

I've been ignoring the fact that my adjustment layers (curves, gray mixer, unsharp masking, etc.) have 72 dpi resolution, and simply change the document's resolution to 300 dpi after I flatten the layers before I write out to a tiff file. This seems to be fine, but I guess I don't understand what impact the resolution of an adjustment layer is. Will it make a difference during my editing if I make all the adjustment layers 300 dpi?

It doesn't make a darn bit of difference when editing images because software programs use pixels. Period. (If your image is 4,000px by 2,400px., edits and adjustments happen to those 9,600,000 pixels.)

DPI (or PPI) only comes into play when the pixels of the image need to be converted to a measurement like inches or centimeters when the image is printed.

Just for the sake of convenience, I've got PL set to use a default of 96ppi because with Win7 on my monitor that's what the resolution is. In other words, when an image is displayed at 100%, what I measure in PL as 1 inch is really seen on-screen as one inch.

And what about 16 bit, instead of 8 bit for adjustment layers? I'm trying to keep a full 16 bit workflow, and the 8 bit layers bother me a bit, but I haven't seen any apparent differences in the on-screen or printed images when I change these layer parameters.

You're absolutely correct in maintaining a full 16-bit workflow. There are people who try to justify their favorite image editing application's lack of support for 16-bit images by claiming you don't need to edit in 16-bits because monitors and printers are only 8-bit. That rationalization is nonsense, of course. Here's what Adobe has to say about it in their help file for Photoshop:

(Photoshop) For critical work and maximum preservation of image data, it’s best if the image you work with is 16 bits per channel (16-bit image) rather than 8 bits per channel (8‑bit image). Data is discarded when you make tonal and color adjustments. The loss of image information is more critical in an 8‑bit image than a 16-bit image. Generally, 16-bit images have a larger file size than 8‑bit images.

I've experimented with making adjustments to the same DNG converted RAW file from my LF1 in 8-bit and 16-bit mode and I can see a very subtle difference -- the 16-bit images capture more subtle tonal transitions. This is apparent even though my monitor is 8-bit. Zoomed in to 200% or more, the 8-bit edited images have areas that are the same tone while the 16-bit images show tonal transitions in those same areas.

By the way, thanks for pointing out that PL creates 8-bit adjustment layers even when the image is 16-bit. I don't think that's right and I'll file it as a bug.

[Hoogo]

So you have changed the resolution and pixel size manually after creating the adjustment layer?

You will see a difference when you paint with a black pen into the mask of the adjustment layer. You can only paint with the low resolution.

If you have changed the resolution only and kept the size in pixels, the adjustment layer will be far bigger than the background. You have to zoom out a lot to see its borders. I don't see a good purpose for this. Maybe there is a usage with virtual copies, but I don't have a really good suggestion for now.

If you have changed resolution and pixel size, you will save a lot of RAM, roughly 95% for this layer. And that's very handy when you don't need a mask with a good resolution. By the way: You can also add adjustments to a vector layer, you can save even more RAM and still have nice gradients this way.

Masks, no matter if the masks of adjustment layers or normal layer masks, are always treated as 8Bit. That's quite a pity, I think.And there's also no interpolation for the lower resolution.

EDIT: Ah, today you have to change the antialiasing in the layer attributes to "always" to have an interpolation during work!
EDIT2: No... That just applies to normal layers, not to masks. Unless you apply "fix layer" to the mask...

[photoken]

Masks, no matter if the masks of adjustment layers or normal layer masks, are always treated as 8Bit. That's quite a pity, I think.And there's also no interpolation for the lower resolution.

??? For a 16-bit image, I can create an adjustment layer, and change the adjustment layer to 16-bit. Then I can create a mask for that adjustment layer and change the mask layer to 16-bit. At least that's true in PL 18.40b3....

[Hoogo]

Masks, no matter if the masks of adjustment layers or normal layer masks, are always treated as 8Bit. That's quite a pity, I think.And there's also no interpolation for the lower resolution.

??? For a 16-bit image, I can create an adjustment layer, and change the adjustment layer to 16-bit. Then I can create a mask for that adjustment layer and change the mask layer to 16-bit. At least that's true in PL 18.40b3....

Yes, but they are still treated as 8Bit, see the test picture attached.
The values are stored as real 16Bit, and when you reduce the layer to 8Bit, dithering will be applied.
But I think that there should not be any visible steps if the calculations with masks were done in 16Bit.

[asharpe]

Thanks, all. So how can I default new adjustment layers (all layers, in fact) to be 16 bit?

[photoken]

Yes, but they are still treated as 8Bit, see the test picture attached.
The values are stored as real 16Bit, and when you reduce the layer to 8Bit, dithering will be applied.
But I think that there should not be any visible steps if the calculations with masks were done in 16Bit.

I don't understand what you mean when you say "they are still treated as 8bit". If "the values are stored as real 16bit", then it's being treated as 16-bit, isn't it?

Your sample image uses a Histogram adjustment layer that is set as "Monochorome", which specifically has a 1 Bit "depth". I can create a 16-bit Histogram adjustment layer (set as a "Gray" image) and achieve the same step values. I think there should be visible steps in your sample image because that's what the Histogram adjustment layer is doing -- severely limiting the input values.

[Hoogo]

Yes, but they are still treated as 8Bit, see the test picture attached.
The values are stored as real 16Bit, and when you reduce the layer to 8Bit, dithering will be applied.
But I think that there should not be any visible steps if the calculations with masks were done in 16Bit.

I don't understand what you mean when you say "they are still treated as 8bit". If "the values are stored as real 16bit", then it's being treated as 16-bit, isn't it?

Your sample image uses a Histogram adjustment layer that is set as "Monochorome", which specifically has a 1 Bit "depth". I can create a 16-bit Histogram adjustment layer (set as a "Gray" image) and achieve the same step values. I think there should be visible steps in your sample image because that's what the Histogram adjustment layer is doing -- severely limiting the input values.

I've made a little change to the file and dropped the resolution thing, that makes the effect a bit more visible and impressing. The same applies to layer masks, so I added one, too. But you are somewhat right, it seems things are even more complicated.

There are 2 adjustment layers in the file. The upper one is just a common trick to check if there are any steps in the picture below. It makes steps more visible and countable, if there are any, and I made it monochrome to save memory, I didn't need its mask at all.
The second layer in the file, named 16Bit, contains a gradient going from 240 to 255. You can check that when you select this layer and the gradient tool. This one is the interesting layer.

The background is gray#127. The histogram correction turns it into a gray#166. That's the value you would find if the mask was completely white and so overlayed with 100%.
Now there's that gradient in the mask, the opacity is reduced to about 94% to the left. With the darker background shimmering through, the color turns to gray#164 there.

When you convert the gradient layer to 8Bit, then the 16Bit values are read and dithered to 8Bit. The result looks smooth and fine, close to the thing I would expect with 16bit.

There should be at least 500 steps if the 16bit masks were treated as 16Bit, but there aren't. Treated as 8Bit there should be 3, but I see 16. I have no idea why

[bkh]

There should be at least 500 steps if the 16bit masks were treated as 16Bit, but there aren't. Treated as 8Bit there should be 3, but I see 16. I have no idea why

That's because the gradient in the adjustment layer has 16 steps from 94% (240) to 100% (255). The result from histogram correction itself should be full 16 bit, and the mixing takes place at 16 bit -- it's just the transparency which has a limited number of steps.

While I think that such 8 bit masks are sufficient for most purposes, I don't quite understand why 16 bit masks get converted to 8 bits first (I can't check this myself now because I don't have PL here).

Cheers
Burkhard

[Martin Huber]

While I think that such 8 bit masks are sufficient for most purposes, I don't quite understand why 16 bit masks get converted to 8 bits first (I can't check this myself now because I don't have PL here).

I will change that.

Martin

[Hoogo]

I will change that.

Just a question: Was this a bug or a feature?

[Martin Huber]

I will change that.

Just a question: Was this a bug or a feature?

It's neither.
In my opinion 8-bit masks are sufficient, and until now I haven't seen a real-life example, that needs 16 bits. And most of the time the mask of adjustment layers is unused, so if PhotoLine can save memory, it should do so.

Martin

[evren]

8-bit masks are sufficient, and until now I haven't seen a real-life example...

Hi;
Me also didn't see but regarding to demands, looks like it's used and there will be an update.
I just want to ask, the default behaviour will continue as 8bit or not? Because I already have RAM troubles in big scale works.

[Hoogo]

I just want to ask, the default behaviour will continue as 8bit or not? Because I already have RAM troubles in big scale works.

RAM-Troubles?
If you don't need a mask at all, you can create a new layer using "Layout > vector > fit in vector layer" and then add an adjustment to it using the adjustment dialog.
Or reduce the resolution of a mask, I assume you already got that idea from our thread. Or turn it to monochrome.
Check for enabled transparency/Alpha channel in layers where you don't need it.

[evren]

If you don't need a mask at all, you can create a new layer using "Layout > vector > fit in vector layer" and then add an adjustment to it using the adjustment dialog.
Or reduce the resolution of a mask, I assume you already got that idea from our thread. Or turn it to monochrome.
Check for enabled transparency/Alpha channel in layers where you don't need it.

Thank you for your help.
Actually I do all except the vector mask. It was not supported in softwares that I used before. That's why I even didn't think about it
Normally 80% of my mask needs for cut-out's. But in case of whole canvas size gradients I'll prefer to use it.
I just would like to ask to make it more flexible, is there (tricky etc.) a way to use normal gradient tool for those vectors?
I don't want to steal from your time to explain me, but if you can I'll be so thankful.