What are the most important improvements for v5?

I agree, although I mean a radial mask version of the gradient tool. These are very popular tools in Light Room and Capture One. Not having them in DXO is a significant negative for users coming from other software as they are regarded as a “basic” masking tool. DXO wants new users :slight_smile:

To be clear are you asking for the same thing or are you asking for a variable area selection for U-Points?

Ian, I confess that I don’t quite understand the precise difference you make between these two definitions/descriptions :thinking:

Sorry I will try to clarify.

A Radial Mask is effectively a “painted” mask like the brush and gradient masks. The shape of the radial mask and the feathering is adjusted by selecting and moving the indicator lines. You have a choice of having the mask “inside” or “outside” the radial mask giving you two masking options in one. I hope the following two images demonstrate what I mean:


Apologies for the mask colour it is user definable :slight_smile:

U-Points are Auto selection masks rather than “painted” masks and make their selection based on the colour/tone of the pixels under the Control Point centre spot. Currently the selection “area” is broadly restricted to a user defined circle. An improvement would be to be for the user to be able to vary the shape of the selection area.

There is a fundamental difference between a Control Point and a mask in that the Control Point is selecting pixels within an area, based on colour and tone, whereas the mask is simply a defined area in which all pixels are impacted equally (except for the feathered area) by any adjustments. With a Control Point only the selected pixels within the area are impacted by any adjustments. The image below shows a Control Point and the selection area circle which limits the area of pixels the Control Point looks at.

I hope I have clarified my post. Radial masks are now available in most mainstream image editors and the lack of radial masks in DXO is a barrier to new users switching as they have become “standard” masking tools.

When DXO introduced Clear View it was soon copied by Adobe (Dehaze) and this tool has now become a “Standard” editing tool that is found in all mainstream image editors.

2 Likes

well Clearview and Dehaze (in silkypix) isn’t the same.
clarity and dehaze together is as Clearview.


original

100% negative clarity

100% clarity

100% dehaze

100% clearview plus. (that’s a combination of clarity and dehaze together.

the shocking microcontrast 100% and clearview 100%

dragging out the microcontrast by slider.
video comparison

The clearview plus is smarter but more limited in fine tuning.
it is adding more microcontrast in a smart way wile you turning the slider up for more “Dehaze” aka blacklevel.
result can be over sharpend. and because it difficult to see before exporting (70% rule and no primedenosing in preview (denosing and sharpening are bound) using clearview in massive amounts is dangerous.
That’s why i like the toolbox in Silkypix for this kind of image’s.
Clearview plus is a automated system wile the other is more manual which is better in extreme images.

i assume dragging the outer oval means more feathering?
My main concern in this kind of tools is a overload of possibilities can cause choosingblock.
Upoint and this isn’t comparible. two different type’s of selection and coverage.

If they add this i think they should drag the "afbeelding
out of this and create a “quick button” next to “repair”
and so we can choose “classic radial filter” as we have now and this oval/round one.
like we can in repair:

So the Brushes and controlpoint can be left in locals. (maybe a HSL control inthere? :thinking: :heart_eyes:)

I do see purpose of this oval/round radial mask. :slight_smile:

Thanks for clarification! In this case, my idea would rather correspond to your second proposition: a variable shape for U-Points.

I’m curious, fellas - Why would you like to see this “improvement” ?

Note: This is being discussed here too.

John

Obvious: when the area I need to correct is egg-shaped / long-shaped / narrow / rectangular / etc, I don’t want to have to “tile” circles:
1° that’s a chore
2° that’s imprecise
I don’t like to draw with a brush either: that of PL is coarse, and it’s again a slow process.

As a very recent Fuji convert (after 15 years of Pentax), X-Trans support is the most important for me. I can’t continue using DxO otherwise. :cry:

Besides that, the only new feature I really missed is a better highlight reconstruction (like RawTherapee’s Color Propagation).

2 Likes

So, how many different Control-Point shapes do you reckon you’ll need ?

1 Like

An elliptical tool (like the “radial filter” in Lr) deals with 80 % of the cases, quickly and simply. (A “quadrangular” mask would be the icing on the cake.) — After all, geometrically speaking, the circle is never more than an impoverished ellipse :stuck_out_tongue_winking_eye:

I do not quite understand your insistence on countering this very natural proposal. As we say in French : « N’en dégoûtez pas les autres ! »…

1 Like

Especially long elliptical shapes I use very often in my reportage work. To reproduce such in dxo is a chore. For one that I did yesterday I need about 7 or 8 circles and still the results was not 100% right to me.

Such mask would also be ideal to do vignetting in a creative way using exposure controls. That is turn means the mask needs to be able to be applied to outside the picture frame.

That’s a fair point; but I’m not simply being negative … I do have an “ulterior motive”; I’ve seen so many posts on this forum where it’s obvious that the poster does not quite understand how Control-Points are actually applied (tho, I’m NOT putting you in that category, Scribe) - - - So, here I’m gently “pushing back” (while not intending to be “dégoûter”) with the hope that other readers may ask rhetorically “What is he on about ?!!” - and thereby question their understanding before they vote for this suggestion in the mistaken belief that it will determine the shape of the selection.

PS. I actually agree that an elliptical U-point would be a handy shape … but I can already imagine all the new misunderstandings that it would generate !

Regards, John M

1 Like

There are two things that stand out to me that would be major improvements and should be at the top of the list of features to add:

  1. The ability to use the HSL tool as a local adjustment. The HSL tool is great but not being able to use it as a local adjustment is a major limitation.

  2. Radial mask. Just minutes ago finished watching an episode of Hands On Photography with Steve Brazill as the guest that focused largely on using radial masks in place of vignettes because of the additional control a radial mask gives you. Not the only use for a radial mask by any means but a good example of how it can be used.

There are other improvements I would like to see but those two stand out as things that would most improve my editing of photos in PhotoLab. I know I’m not the first to mention them but I figured I would add my thoughts anyway.

1 Like

The ability to Folder create, rename, move, copy and delete inside PL on a Mac

You are talking about Source Browser in Library view? Additionally there should be functions to sort folders (like in Finder, by date created/modified, size, tags…). Also, there should be a tag to show if folder contents are indexed and/or adjusted/developed, maybe also if contents have been changed after last editing session.

2 Likes

Tall order, but I would like to have a unified merge feature, which would take a bunch of photos and merge them to HDR AND panorama, as well as source material supports that. That is, overlapping photos would combine to larger views (not necessarily just panorama but also expanding to all directions there is image data), and overlapped parts would try to adjust tonal data optimally (call it HDR). Supply necessary flips and switches to allow user adjustments. Export (and reimport) as DNG (or why not 16- or 32-bit TIFF).

I’m a Fuji user since Day 1 of the X100. And since the X-Trans cameras came out, this has been a repeated theme. I think the reason is that PL digs into the native RAW formats and they are all BAYER arrays. To make some of the advanced PL features work for X-Trans might require DXO to build an entirely parallel set of code, for what is still a pretty small market share (though a larger percentage of Fuji X-Trans users might be Pl customers – when compared to the rest of digital photographers).

I use PL 4 and like it a lot, but I convert my RAF files with Iridient X-Transformer. I have to use a different camera brand/model to save in the metadata to get those DNGs past PL’s filters (PL does not accept linear DNG files that are tagged with some camera brand information). You don’t get the most advanced PL features, but I still find the software to be very good, though a different look and feel than PhotoShop (which has a relationship with some of the processes used in pre-press workflows).

1 Like

1. The ability to accept linear DNG files. I do most of my digital photography with Fujifilm X-Trans cameras. I totally “get” DXO’s position that they will never, never, never allow PL to process native X-Trans RAW files. (I believe the reason is that the level of effort required to build parallel code to allow the processing of non-Bayer files is uneconomical – based on potential sales.)

What I don’t understand is why PL4 can’t handle a DNG file created by 3rd party DNG converter – such as those from Iridient X-Transformer. But actually, PL4 does accept those files – as long as they are tagged with another camera brand’s information during Iridient’s conversion. I’ve tested this with several different X-Trans file formats. So it appears that DXO has some kind of a lookup table that specifically excludes Fujifilm X-Trans files. The rationale escapes me, since Fuji owners have been requesting access to DXO for years.

There is a downside: A few of the most advanced PL features seem to require a camera’s native (Bayer) Raw file to function. I “get” that too. But I can do noise reduction in Topaz AI and still get 95% of the benefits of PL. After years of PhotoShop, PL works in a completely different way, but going back over several years to look for some of my more challenging post-processing situations, PL has done a better job with less effort – and those were from DNG files made with a “spoofed” camera brand/model.

There is no technical barrier – it is just a DXO attitude barrier.

2 Likes

Hi @LJClark,
Thanks for your feedback.
Some of your assumptions are correct, but others don’t.

Correct

  • It’s true that making PL available for X-trans will need us to rewrite our algorithms. Impossible? No.
    A very long and time-consuming process? Yes.
  • A “forged” :sunglasses: linear DNG created on Iridient X-Transformer can be used in PL: probably yes.
  • “It appears that DxO…excludes Fujifilm X-Trans files”… :thinking: (see below)

Incorrect

  • “DxO will never handle X-trans native RAWs:” DxO never said anything like that :wink:
  • “It appears that DxO…excludes Fujifilm X-Trans files”: PL does not process files that can’t be properly handled, not because this is our stance, but because this is what is all about…
    PL has been created since the beginning to deliver the best image quality, period. If you use a DNG for which DxO doesn’t have any calibration profiles, we can’t do much with your image, at least, we cannot deliver what our product is supposed to deliver.
  • “There is no technical barrier, it’s just a DxO attitude barrier”. There is no attitude, or ideological stance: the barrier is only technical. If we do not rewrite our algorithms there is no X-Trans possible. If we do not create the calibration profiles for X-Trans cameras, there is no X-Trans possible in PL.

As a photographer using our product I can fully understand your frustration. You’ll be amazed knowing that your frustration is shared by some of our colleagues here at DxO, who are avid Fuji users…
For now, this is the current state of X-Trans in PL.

Steven.

1 Like

well, @StevenL, some of what you write can at least be discussed:

While it is true that if you don’t have algorithms and modules for Fuji gear, you cannot treat Fuji files to the same level as supported Canon/Nikon/Sony… files, we could still use all other tools that DPL provides (Unsharp mask, Exposure, white balance - need I write more?)

There is much more room than what we create with either/or: Take a rainbow, reduce it to infrared and ultraviolet and we’re left with nothing visible…

1 Like

Steven,

Thanks for your response. Up to this point, the best I was able to get from DXO was a “I’ll pass your concerns on to < ______ >”.

First, please remember that in my comment in this forum I asked for, in PL5, “ The ability to accept linear DNG files .” My comments concerning PL not ever accepting X-Trans native RAW files were primarily to ensure that you understood that I understood the considerable level of effort it would take to build X-Trans native RAW support into PhotoLab. Another part of that comment is a suggestion for X-Trans shooters to look past that limitation and consider PL for its remaining features that work with TIFF, JPEG, and DNG files – and which are quite good.

The issue remains DXO’s blocking of DNG files that contain metadata that identifies the camera as a Fujifilm X-Trans camera. Or maybe it is more accurate to assume that PL will only intake files where the metadata matches a list of cameras that are approved. But that continues to puzzle me.

You concerns regarding the results in PhotoLab from unknown DNGs may be legitimate, but only to the extent that the “unknown” might become the “known” with a little outreach. Has DXO ever talked with Iridient and asked for samples of their DNG files produced from X-Trans RAF files? Iridient was very helpful to me, and even suggested how I could tag the DNG files (set up to be done during conversion) to represent a sensor that had properties similar to the sensors used in Fujifilm cameras. I have successfully converted RAF files from X-T3, X100F, X100S, X-Pro1, and X20 cameras. All of those files worked in PL4 if they were tagged “properly”.

A final note on my comment “ DXO ’s position that they will never , never, never allow PL to process handle native X-Trans native RAW file s ”. For Fuji X-Trans shooters, the current situation is indistinguishable from “never”. But that’s reality, and there is an acceptable way to use linear DNG files, converted from X-trans files, in PhotoLab.

Get some of your in-house Fuji shooters together some day and we’ll Zoom.