Hmm, falling back to sRGB is really the best option as that seems to be the most widely used option in various softwares, so less room for confusion.
Instead of having “sRGB” in parenthesis in the UI, what about an “on-hover” tip that says sRGB will be used if no embedded profile is found? Or even just a note in the “help” section? and then remove the essentially duplicate other “embedded” option?
Some softwares provide an additional option to use some other user-selected profile (other than sRGB) for images without embedded profiles. But this option only helps people with a very specific workflow where something other than sRGB is the most common profile that will be assigned for images without embedded profiles (for example people loading scans that don’t have an embedded profile, and to which a custom profile needs to be assigned).
So this additional option could be provided as a user option in PhotoFlow, but maybe only if users actually start to ask for such an option?
I think I will end-up following your last suggestion. If users have some non-sRGB image without embedded profile, then I expect they know what they are doing and are able to select the right input profile in the UI.
@Carmelo_DrRaw Actually, PF is going to fallback on import even though I exported the TIF with an embedded profile.
Re: profile management, I would prefer it to be done this way:
If it is a profile that comes with PF, then the selection menus would reflect that.
If it is another type of profile, then selection would be “custom: [full name of profile]”. If the gamma could be detected, then the secondary selection would reflect that.
If there is no profile, assume it is sRGB (standard gamma) but indicate it is a “fallback”.
In all cases, input and working would be the same by default.
PS There is a minor redraw issue. Sometimes when I open, crop or zoom an image, the image is drawn with the wrong zoom for fit image, and even though it is larger than fit, the user cannot scroll the image. It is easily rectified by redoing the action.
That’s really strange! Could you provide me an example of TIF file that shows such behaviour, so that I can check what’s going on?
What you propose makes totally sense, but is not trivial to implement in the current UI… what I will soon offer is an info panel showing EXIF data as well as the details of the profile being used for the processing. There is will be easy to specify if the profile is an internal one, a custom one or the “fallback” sRGB.
This is already the case, because the default setting for the output profile is “use embedded”, which should probably be re-phrased as “use input”.
I also noticed this, but so far I could not really find the root cause of this issue… as it is not triggering any crashes, I have however put this into lower priority for the moment.
@Carmelo_DrRaw Here is the TIF: https://filebin.net/ztsne92tuvjq52xx. It is just DSC00989.ARW opened in PF and exported without any settings changed. Should be Rec.2020 Linear by default. This has been happening to me a lot. I didn’t bring it up because I didn’t have the time to think about it and report it.
Like you said, all is fine. The histogram checks out. Cannot tell from the image since I am currently on a sad screen. I could have sworn that something fishy was happening… Maybe I will make a note next time I find something. That way I won’t forget how to repeat it . I have one more thing to check later and I will update this post when I do.
PS One thing that is misleading currently (and I have pointed this out already in two posts) is that it says embedded (sRGB) even though we both know that PF isn’t using the fallback sRGB. However, when I change the selection menus in input and working to the correct items, the histogram doesn’t change, so in the back end all is fine.
For the life of me I cannot bend the string, Carmelo, Doctor deRaw what have PhotoFlows been eaten that lumamasks are constipated both in the unstable and the continuos unstable but linear but guuud??? !!!
I have a little idea, would it be possible to make a feature where duotone gradient which follows a pattern of steps. I just had a recent experience trying to make L0-65535 by hand as the available filters I am having doesn’t really deal with LAB, and there is shifted value if I were to use G’MIC filters. I had to copy and paste “+64” over 1000 times by hand. You get my drift?
That is not what I’m asking of. I’m thinking of gradient of L channel where the increment of increase are value based off division of width or height. Let’s say I want L gradient in 1024*1 canvas. I should be able to see each increment of pixel go by 64 in 16-bit. Tried gmic, values are thrown off.
Sorry, questions and answers have been crossing… my previous answer was for @chroma_ghost, while I am still thinking about what you propose and what I could offer…
If you want to generate a linear gradient as you describe, here is what you should do (see also screenshot):
open whatever image (photoflow cannot for the moment generate an image without an existing input)
make sure that the working profile is sRGB with the standard or perceptual encoding (if you need a different colorspace, just let me know and I will be more detailed on this point). The crucial thing is to make sure that the working profile has a non-linear encoding, because the gradient tool behaves differently in linear-gamma colorspaces
add a crop layer and crop the image with a width of 1024 pixels and the width you prefer (I have used 10 pixels in the example below)
add a gradient layer and set the direction to horizontal
At this point, the 1024 pixels are filled by greyscale values equally spaced from 0 to 1 (as we are in floating point precision). Converted to 16 bits, this gives constant increments of 64.
This was something that indeed got broken when I merged the branches… it is fixed now, you should get new packages soon.
I am still trying to understand the origin of those spots in the over-exposed case… I suspect some problem with the gamma adjustment. Are they still visible if you sett gamma=0?
Hope so. The linear_gamma branch exhibited this problem for me previously, and I always use linear gamma…
PS While this post is hot, I might as well tag on a question and / or request. When I import another image layer, is it possible to re-position it relative to the other layers? If not, I would like there to be that feature. Often the import has different dimensions from the opened one and I don’t want it to be at the top left corner all of the time for obvious reasons.
This was something that indeed got broken when I merged the branches… it is fixed now, you should get new packages soon.
Okay will check that out when travis do the moonshine continuous flip flap. Ti ringrazio molto cugino uccello
I suspect some problem with the gamma adjustment. Are they still visible if you sett gamma=0?
good suspecting, I suspect too, it has always been the case that indeed the gamma slidder makes the child burp ,-) . They’re (little digital aliens) gonne in gamma zero
Indeed, generating gradients mathematically is safer. However, as I have shown in the other thread, it is always good to double check by pixel peeping and sampling.
. I have one more thing to check later and I will update this post when I do.
je jejej je it is gud for yu