Jump to content
rui_mac

Why does Dodge and Burn tools don't work on masks?

Recommended Posts

59 minutes ago, R C-R said:

They can be represented as a greyscale image for editing & visualization purposes but the opacity alpha channel is not actually a greyscale image. For that matter, neither are the RGB channels. Each of them is just a set of numeric values in an RGBA color model.

Exactly as all image files are.
They are just lists of numbers.
And those lists of numbers represent colors, greyscales and opacity values.
And those opacity values are represented as greyscales.
And, since you can perform operations on these lists of numbers (painting, blurring, smudging, dodging, burning, apply filtersetc), it should all be possible in CMYK, RGB, greyscale and alphas.

Please, tell me, R C-R, what is the difference, internally and numerically, in the list of values of a greyscale image and the list of values of an alpha?

Share this post


Link to post
Share on other sites

After reading this thread I only just realised the original date of this: 2016!

So let me add my 2 Euro-Cents to this topic,I usually use every tool in my belt to adjust transparency of my layers in my compositions. By multiplying channels, locally dodging, burning, making an outline and blurring it - then expanding by gradation-curves and subtract the result from my original channel, and so on. Also, I often need to go back and dodge or burn one nasty part of this mask, AFTER I have imported it in my layout (Indesign/Publisher) 

I have not made the jump from PS yet, but I purchased Photo and looking forward to switching. I have not had the time to fully test all my workflows in it.

Disclaimer: Used Photoshop since 2.0 - that's before Layers so I learned to appreciate the use of channels, and I mean painting through selections on top of channels which I would then use as the final selection... So, yeah pixel-selections ARE alpha-channels ARE grey-scale images which you have to be able to manipulate as that. 

 

And no: Painting does not do the same to an alpha-channel as dodge or burn. In this Screen-grab of Photoshop I tried to tighten the mask with dodge or burn and remove the gaps – maybe someone can post an example with hair...

 

 

  • Production-System: iMac (21,5-inch, Late 2013), 16GB RAM, 2TB nvme-SSD, running on 10.14.5 Mojave;
  • Display Setup: 27" Thunderbolt Display primary + 21,5" iMac-Display secondary for palettes;
  • Keyboard-Layout: German apple extended keyboard (aluminum);

 

Share this post


Link to post
Share on other sites

The main reason that I don't ditch Photoshop completely is the way Affinity Photo deals with alpha channels.
It is so much more intuitive in Photoshop, since alphas are just greyscale images and you can do to them whatever you can do to a regular greyscale image.

Share this post


Link to post
Share on other sites
1 hour ago, rui_mac said:

Please, tell me, R C-R, what is the difference, internally and numerically, in the list of values of a greyscale image and the list of values of an alpha?

Surely, it is obvious that the difference is that they describe different things. While a greyscale image can be created from a color or alpha channel, that does not make them the same thing, any more than creating a rasterized image from a vector drawing makes them the same thing.

Please don't misunderstand or misrepresent what I am saying. I am not in any way objecting to improving or extending the tools that can be used on masks in Affinity Photo, including the Dodge & Burn Tools if you would find that useful. In fact, early in this discussion I said as much. My only objection is suggesting that alpha channels somehow are or are equivalent to greyscale images. They aren't, not in Photos, not in Photoshop, not in any graphics application, & they never have been.

Imagining that an alpha channel is simply an "extra" channel, or that the red, blue, & green channels are simply greyscale images "by themselves" may well be convenient for some purposes but it does not change what they are. Besides, it doesn't make much sense to try to do so if you are not working with an RGBA image to begin with -- for example, a CMYK image has none of those channels.


Affinity Photo 1.7.1, Affinity Designer 1.7.1, Affinity Publisher 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.1.143 & Affinity Designer 1.7.1.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

CMYK images are a set of four greyscale channels, each one defining the amount of Cyan, Magenta, Yellow and Black ink.
Internally, there is no difference in the way they are stored.
So, a greyscale image is a list of values.
An RGB image is a set of three list of values.
A CMYK image is a set of four lists of values.
And an alpha is a list of values, just like a greyscale image. Exactly the same. Stored in the same way.
The way you interpret or use that set of values may be different, but they are all the same type of data, internally.
So, we should be able to use all tools in the same way in all of them.

Share this post


Link to post
Share on other sites

I just created a render in Cinema 4D and asked for an alpha to be produced.
I defined the file format as a TIFF file and asked for a separate alpha.
I got two files: an RGB TIFF file and a greyscale TIFF file.
So, alphas ARE simply greyscale images.
And the same happens in any format.
Sometime, if the alpha is stored as a separate file and the file format does not support greyscales, the alpha is even stored as an RGB image, with all channels storing the same information (three equal greyscale images, one for each of the R,G and B channels).
Of course, that is overkill, as the file gets much bigger.

Share this post


Link to post
Share on other sites
31 minutes ago, rui_mac said:

And an alpha is a list of values, just like a greyscale image. Exactly the same. Stored in the same way.

Just because they might be a list of values that might be stored the same way does not make them "just like" or "exactly the same" as greyscale images.

In fact, we don't even know how images are stored in the proprietary native Affinity file format. The developers have said that it is an "unconventional" format, but aside from a few hints about the use of serialization, mIpmaps, compaction after some threshold is reached, & maybe a few other clues like that an entire Affinity format file is not read into memory all at once, we can't even be sure that a document's channel data are stored individually or as simple lists of values ... or even that this data is stored the same way each time we save it.

Besides, it is clearly not true that this is how all file formats store images. Consider for example JPEGs, indexed color formats, WebP, HEIF, & other formats that use lossless compression, & so on. 


Affinity Photo 1.7.1, Affinity Designer 1.7.1, Affinity Publisher 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.1.143 & Affinity Designer 1.7.1.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
13 minutes ago, >|< said:

You are falling into R C-R's trap, as I have often done. He knows what you mean, but he will pretend to be a fool in order to provoke an argument.

No, I don't know what he means when he says everything is stored exactly like greyscale images (or as if they were greyscale images or words to that effect), if for no other reason than because he must know that there are many formats where that is not true.


Affinity Photo 1.7.1, Affinity Designer 1.7.1, Affinity Publisher 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.1.143 & Affinity Designer 1.7.1.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

I know all about storing methods. I teach my students how JPEG stores data. And how indexed colors (GIFs, for instance) or mipmaps work.
But when a file is loaded, even if there is some sort of internal storage scheme, when reading, writing or manipulating the data, all that data has to be accessed as raw data.
I know how that is because I code my own tools and deal with all types of data.

Share this post


Link to post
Share on other sites
6 minutes ago, rui_mac said:

I know all about storing methods. I teach my students how JPEG stores data. And how indexed colors (GIFs, for instance) or mipmaps work.
But when a file is loaded, even if there is some sort of internal storage scheme, when reading, writing or manipulating the data, all that data has to be accessed as raw data.
I know how that is because I code my own tools and deal with all types of data.

With all due respect for your knowledge & experience (& please believe me that I do have a great deal of respect for that), how could you possibly know exactly how the native Affinity file format stores image data internally, or how the Affinity apps access it?

The developers have made it very clear that they consider the native format to be unique, in part because of its unconventional for a 2D app use of mipmaps, together with data serialization, what seems to be a database-like file structure that enables non-sequential access during loads & saves, optimization for high memory efficiency at the expense of increased file size, & some other stuff they remain unwilling to discuss publicly.

All this strongly suggests that not everything in the file format is pure raw data, that at least some of it in addition to the mipmaps is stored in some unspecified fully or partially processed form, that it can be read from & written to the file in chunks that in some way may mimic how OS level memory managers work, or in some other way is truly unconventional, just like they claim it is.


Affinity Photo 1.7.1, Affinity Designer 1.7.1, Affinity Publisher 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.1.143 & Affinity Designer 1.7.1.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

The native format is very structured, I know. And that means that is very compact when saved and also when in memory.
But, and this is a big but, if it is possible to paint or blur the alpha data, then it is possible to Dodge and Burn also.
If the alpha was stored in such a way that it was not possible to darken or lighten the values (in fact, dodging and burning are simply the increasing or decreasing of the values), then it would not be possible to paint on alpha too.

Share this post


Link to post
Share on other sites
3 hours ago, Nekodificador said:

So... any solution?

An actual solution? Something like this.. or probably just the 20GB Photography plan.

Thank you for your payment.
We received your payment for your Creative Cloud Membership. To print your invoice, open your Billing History or follow the instructions at the bottom of this email.


"Men are like sheep, of which a flock is more easily driven than a single one."

Share this post


Link to post
Share on other sites
2 hours ago, Jowday said:

An actual solution? Something like this.. or probably just the 20GB Photography plan.

Thank you for your payment.
We received your payment for your Creative Cloud Membership. To print your invoice, open your Billing History or follow the instructions at the bottom of this email.

Interesting, you’re joining an three years old thread you never posted in, and, your simple solution is: Go back to Photoshop...

But, when I in another thread urge a user to do a refund of Affinity Publisher and move on from Serif, you give me an bitter comment about my tip... Hmmm... Strange guy...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×