Wumpus
-
Posts
99 -
Joined
-
Last visited
Posts posted by Wumpus
-
-
Side Note: Only had purchased Photo, but tried the Designer V1 demo a couple times, but it wasn't enough for me to understand, however a couple days after v2 came out I bought the Affinity bundle, and I've been enjoying the entire suite quite a bit more. Very capable products, and continuing to mature: thank you Affinity.
-------------------------------------------------------------------------------------TOPIC
Affinity Photo: Develop Personae - Clipped Tones definition, and how to remediate its warnings
No rush on this topic/post, but I would still appreciate a response at some point. This seems to still be relevant for v2.I've tried to figure this out a few times since Spring 2019, and never could get an authoritative answer (lots of well-intentioned forum generated musings, but none of which were applicable).
I do understand ETTR, and underexposed shadows and clipped highlights, but the explanation "Clipped Tones means you have too many midtones" wasn't enough for me to work with." Or here was another, "Show Clipped tones when enabled will show all the clipped midtones areas with a bright yellow colour. This then allows you to use the tools such as Exposure to adjust your image."Based on those explanations, this is what I've deduced... "Clipped Tones are when there are so many mid-tones that they spill out the top of the histogram". 😉
In my previous quests for an explanation of this functionality and how to use it, I have found changing various settings alter the degree of the warning to various extents, but I still can't quite understand it though. Yes, I do also keep checking the help file every few months.
I encounter this warning a fair bit, and have been hoping for guidance on a way to deal it. Thank you!
-
I was excited about the measurement tool announced for V2 Designer, but it turns out it's just for ad hoc, one-off distance checking. I'd strongly recommend making the measurements persistent for reference (use case #1: multiple measurement call outs as drawing objects), and even better, anchored between points and being dynamic during repositioning (use case #2: live measurement feedback between measured targets), so you can easily place an object X distance from something, without messing around with the objects position or '0' reference points.
Someone said these features are for CAD packages, but I'd like to point out that the last word in the acronym CAD is 'Design', plus even 'ruling out' CAD apps, it is also a staple capability of graphic design apps (CorelDraw, Micrografx Designer, Inkscape, most 3D modelling apps).
Right now, the good dev teams are certainly flooded with requests, but this is my suggestion for adding this rather important functionality for queuing consideration in your next grooming/prioritization/costing session. It certainly helps more comprehensively knocking out your competitors, so it has some marketing value too. For the meantime, I'll export my vectors and bring them into Draw, but it would be nice to accomplish all within Designer.
-
Thank you @walt.farrell and again, I might add. Was hoping for a timeframe, such as backlog grooming frequency and priority.
For a product with some great development, the support seems to continually let me down with rare responsiveness (despite checking who is following a post and specifically naming its audience, as you taught me in similar historical circumstances).
It always falls upon the user community, such as good folk like yourselves, to speak up for the product owners and product support teams. I wonder how any other organization would feel if I took it upon myself to publicly act as their public representative, on their behalf. Users have zero authority and accountability, plus incomplete knowledge, exactly because they aren't Affinity employees. Its a highly unusual and new Management technique for the business world.
Further, the double-speak of "logging" infers someone will review it, thought the backlog here appears to undergo a grooming frequency aligned with the duration of the Mayan calendar.
Bottom line, the current model always yields a very brief and very false hope to its customers, which of course always turns to a negative sentiment. I still can't get my head around that peculiar business model.
I fully understand your position, Walt, and thank you for it. I'm just repetitively annoyed at the support model. The customer service team can come out from their cupboards yet again, because as per 'business as usual', a non-employee has had to step in and do their job for them. A sort of RACI chart without the letters R or A.
Thanks.
-
Hi @stokerg
Just thought I'd check in case once something gets 'logged', that means that it's basically back-burnered for eternity, or whether someone was going to address my original question one of these weeks. I do understand this happens a lot, so hoping for a notion of when I might expect some response.
Thanks very much
-
-
-
Just checking in if there's been any progress. I know sometimes things get a bit hectic here, and occasionally things fall through the cracks.
-
Very much appreciated. The SD14 has a much lower usage rate nowadays, and likely will be even less so when Sigma finally releases their upcoming model (2022/2023) that should work similarly (except be full frame), so that has lower importance for me, and likely similarly for your other Sigma users. The SD1M is still in heavy use by the Sigma community, and would be a higher priority to accommodate. Anyway, that's just some marketing context, if that helps.
I never realized that there should be thumbnails: that woud be quite helpful! Thanks again so much again for your consideration.
-
Hi @stokerg:
Thank you so much for investigating this, and my apologies for not getting back sooner (12-14 hours days in a crazy time of year).
I did tests using an Sigma SD14 and an Sigma SD1M, both of which are 1:1:1 X3F raw files ( a bit unlike the Quattro Sigmas, and very unlike the 'fp' Sigmas, if that's of help). I varied the available controls presented through the "New Stack..." dialog, so you could see the results in the dump file with a variety of different settings. The files are in your drop box: two SD1M files and two SD14 files, and three dump files representing all the various settings.
As 16-bit TIFFs, these same images work flawlessly in the same steps, so I have a workaround. Unfortunately, Sigma makes getting quality images out of the X3Fs a bit work work, so it would be convenient to do it through AP, but if too much effort, I'll understand (I also do development).
The main reason I mentioned this is that most Sigmas use a very unusual raw data format, and so you don't treat them identically to other CFA raw formats (which is good: those changes you made drastically improved your X3F handling, and I am a grateful user for that). Which led me to think (again, as a developer) that perhaps this routine was undergoing the same processing as for other raw formats, and so crashing. Perhaps (and yes it's one more tiny bit of code baggage) a condition could be put in to check the format and route it appropriately.
Anyway, that was my little idea and request if someone could see how onerous that was.
Keep up the good work.
-
Hi.
Retried some image stacking recently, and it is working amazingly well. Bravo. Excited for 2.x. It would be completely usable for me now, for focus and tonal mapping, and panorama.
Just wanted to mention that importing any extent (# images) of any kind of stack using X3F (raw format) results in a crash to desktop.
However, bringing the files in using a 16-bit (per primary) TIFF works very well.
Reading posts here, it mentions that you lose the automatic raw Development persona doing Stack image loads (which makes sense). But it sounds like it is still feasible (though streamlined) using other raw formats. I also know that X3F gets handled a bit differently than other raw formats (it's not using LibRaw).
My question was if a Dev could check whether that crash to desktop occurs because AP is treating X3F like other raw formats (maybe there's another existing group that wouldn't use LibRaw, and so would work better with X3F). If so, it would certainly be extremely convenient and appreciated if that could be fixed.
If it would be all custom Dev work, then its not high priority, as it is still functional using TIFFs, and its just a bit more prep work.
Thanks very much.
-
Latest beta 1.9.0.820, after upgrading, when choosing Sign In Now... I get the horizontal Please Wait a Moment (with neon animated activity) for several seconds, then a crash to desktop (CTD).
Note that I haven't tried the 1.9.0.815 beta, so this is my first time trying this new login approach from within the app: I can't say if it would have also happened with the previous release.
I run BitDefender, but it doesn't report having blocked any network or suspicious activity. When I re-launch AP, I see in my Task Manager that a 'crash-handler' applet also runs (I don't know if it ran the first one or two times). Skipping logging in, everything seems like normal program operation, but if I choose "My Account", and I retry logging in, I get the exact same. Repeatedly. AP and the Crash-handler both terminate every time. The only thing for my system that's not completely up-to-date was the latest "2020-10 Cumulative Update preview for .NET Framework 3.5 and 4.8 for Windows 10 version 1909 x64". I just installed that, but must reboot and if it fixes it, I'll post that back here, but I doubt that's my solution.
Exciting to see the developments.
UPDATE: 2020-10-28
- Did the "2020-10 Cumulative Update preview for .NET Framework 3.5 and 4.8 for Windows 10 version 1909 x64" update - no resolution to issue.
- Did the "Clear User Data Dialog" steps (leaving the top default selections checked), and also no impact to the subsequent CTD.
-
BW images opened in the new AP-Beta are almost ideal out of the box, for exposure, colour balance and curves.
In some situations, it is even possible to adjust the individual colour channels like you can when converting Bayer colour images to BW, without adding artefacts. However, in others, it is still not possible to do so (ugly side effects).
In general, the BW images are much noisier, and have some haloing (even with zero sharpening applied) just through the denoising process. However, with judicious use of denoising, you can get the noise toned down enough that not too much detail is lost and the haloing doesn't jump out at you.
I think it might be a good final effort to change the current denoising (however it's being done), either to return to Affinity's denoising or Kalpanika's denoising. The first comparison is zoomed in to see the shadow noise and highlight patterns (300%). Zero sharpening, but moderate denoising as indicated in the AP menu screenshots.
The next comparison is between A) an X3F processed through Kalpanika to a DNG format, then brought into Affinity Photo Beta, and B) an X3F brought directly into the same version of Affinity Photo Beta, to compare noise handling. Note that I had to increase the denoising for the direct X3F opening and processing in the AP beta, as apples-to-apples, it was quite noisy.
As a control reference, here's a couple of other means of processing the same image. As this sample was high-ISO (don't laugh please): I just used the blue channel to minimize the noise.
Above is an export from Corel Photo X7 (not PhotoPaint), (which uses DCRaw to process the X3F), and using only the Blue channel, converted to greyscale. Zero denoising, zero sharpening.
Above is Blue channel export from Sigma Photo Pro (Foveon vendor's app). Zero denoising, zero sharpening.
A key caveat to all of these is that this photo was taken at nearly the camera's ISO limit (400: don't laugh) in noon sunlight (broad dynamic range), which is almost always extremely noisy.
To provide a broader sample of images, here's the F13 sensor in colour, zero denoising or sharpering, opened in Affinity Photo (non-Beta) (below). Note that heavy exposure and colour processing was required to get it into the ballpark of the output from Affinity Photo Beta (further down):
And above is the same image in Affinity Photo Beta, zero sharpening, but moderate denoising. Only exposure and denoising we required.
In about 5-10% of cases, the default exposure and curves weren't really anywhere close to usable, so required lots of effort to tweak something out of the opened image. However, that was also the case for about 75%-90% of the images with Affinity Photo before the beta, as well as most other 3rd-party raw processors (digikam however was much better than average), so Affinity Photo was not at all alone in that regard.
In about 10-25%, noise was quite high, and individual channels couldn't not be altered without introducing side-effects. However, the exposure and colour and curves were shockingly good at default.
While there were a lot more tests, suffice to say that in about 40-70% of the tested cases, moderate denoising was required, and still had a fair bit of noise that could never be mitigated in the shadows, but it wasn't extremely evident at 75% or lower magnification. Again, exposure, colour & curves were shockingly good at default.
In about 25% of the cases, the noise was very low (barely evident), and the RGB channels could be adjusted independently without adding artefacts. That's the ideal situation.
Here's just one example (F20/Merrill sensor taken at ISO100, zero sharpening and zero denoising, default BW conversion {3-channels to greyscale}). The exposure, colour & curves were shockingly good at default.
Apologies for the post length, but hope it gives more to work with and possibly more specific questions for subsequent tests.
😊
-
Wow, what a change, @Andy Somerfield and @Mark Ingram!
I need to do much more comparison work, but the new 'out-of-box' exposure and colour when opening up an X3F is absolutely the best ever. Similar with the BW exposure and contrast.
It's now mind-blowingly easy to work with X3F files for exposure and contrast and colour (normally Sigma/Foveon images require a lot of hand-holding to just get within workable range, and that's largely true for every raw developer).
Noise is possibly the only detriment though: most evident upon pixel-peeping, but still visible at 100%. Perhaps use the Kalpanika denoising? Just early thoughts...
Sigma F13 Sensor X3F opened using non-beta AP 1.8.3.641, with the usual denoising & sharpening turned off.
Sigma F13 Sensor X3F opened using AP-Beta 1.8.4.681, with the usual denoising & sharpening turned off.
I'll point out that I still need to do a lot more work on the first image to get it closer to 'normal' (which the Beta did nearly automatically, just darkening exposure 0.5). The first image required about 10 or 12 changes to get it into its current 'somewhat-close' state.
With moderate de-noising applied to the Beta, there is definitely halo-ing, and only a bit of detail begins to be lost, but it's not too bad.
Now that's with the F13 Sensor. Doing a couple fast tests with the F20 (Merrill) sensor, the improvements are almost night and day better. Again, there is more resultant noise than when comparing the laborious Kalpanika->Adobe DNG extractor workflow (meniotned above) to Affinity on its own, but the upside is that, as Andy says, you just open the file or turn on the BW switch.
If you have specific things you would like checked, please leave them with me as some homework. This is a giant improvement, and doesn't seem to ruin other sensor X3Fs handling (I was worried we might fix Merrill X3Fs and breaking other X3Fs). I need to try a more representative selection of sample images.
This is a huge change, and thank you very much!
- Joachim_L and Mark Ingram
-
1
-
1
-
Thank you @Andy Somerfield and @Mark Ingram.
I will test out the new version in a moment, and report back here. I just wanted to document some further testing I did earlier that might be helpful, but didn't have any chance to make a post yesterday.
I used identical settings with Kalpanika 0.56 and 0.57. I don't know if you use these public releases or have a special version for Affinity Photo.
Here's the same workflow, changing only the Kalpanika version:
STEP#1: x3f_extract_v056.exe -v -dng -color none -sgain -ocl SDIM6813.X3F and x3f_extract_v057.exe -v -dng -color none -sgain -ocl SDIM6813.X3F
(using camera's original white balance, and minimal Kalpanika denoising)STEP#2: Adobe DNG Converter (12.3.0.493) using CameraRaw4.6 compatibility setting, output to DNG
(don't embed fast load data, JPG preview Medium size, Preserve Pixel Count, Don't embed original RAW, Don't use lossy compression)Attached are Irfanview screengrabs from above workflow's DNG output, differering only in Kalpanika version
Kalpanika 0.56 (above)
Kalpanika 0.57 (above)
Opening either in any Affinity Photo Windows does not permit removing channels (such as Red) or using only one channel (such as Blue or Green) without causing image artefacts, and also loses all intrinsic benefits (reduced noise, natural microcontrast, effects from 'stacking').
STEP#3: Open in Affinity Photo 1.8.4.676. Pick WB point (I used white rolled flag middle right), adjust Exposure +0.5, Disabling Noise Removal, Develop, Channel Mixer "Grey" using "Intensity" at 120%, Merge at 100% opacity. Using any other form of colour or channel isolation did not seem (to me) as helpful in anyway, as had been suggested.
This still isn't ideal, but is far less destructive than anything else to date, and provides some panchromatic stacking benefits (but still not much noise reduction or microcontrast).
It also shows some of the differences in Kalpanika version output, particular to Merrill (aka Sigma F20) sensors. I hope these efforts were constructive in some way. I have provided the original RAW earlier, so you can follow the workflow/recipe if you like, or I can provide the two output DNGs if you prefer.
I'll try the new 1.8.4.681 now!
-
Excellent & thanks @Mark Ingram. I just figured you two might want to allocate a non-lead person from a relevant Dev pod, as I didn't want to presume key contributors would be helping me out, but that's fantastic.
Thank you @Andy Somerfield. The rest of this post is for you, and my apologies up front, as I'm dashing this off rather hastily, but thank you so much for your attention.
Yes, In my unaided quest for a solution, I made a post about a year ago that while many RAW developers & viewers observe the BW metadata switch, Kalpanika was one that did not, so I'm aware of that. And my source of bad information is the sparse, contradictory and incomplete support responses I have been receiving to date.
I'm not sure which Kalpanika is being used (0.56 & 0.57 handle Merrills differently, or maybe its something altogether different), but something ugly is being introduced. Maybe going to intermediate RGB rather than mixing three linear channels... Anyway, I'll stop and respect your time. The following comments are verified up to the latest Windows AP Beta 1.8.4.676 (but also since 1.6.x)
- Grabbing the blue (top) layer only should provide incredibly noise free BW images. Great also if using both Green and Blue layers (the Red layer is the typically noisy one). If I do this through the Develop Personae (as I've posted since trialling AP in Dec/2018 through Jan 2019), it's not. If anything, a person's face might turn jet black if I dial-down pure Red only: most people I photograph don't have pure R:100 G:0 B:0 Faces, so that seems unusual.
- In theory, a BW image aggregating all three component RGB layers should see naturally reduced noise (as if from a 3-stack exposure), but that's also not the case. Ordinarily, well-exposed Sigma images can be used with zero sharpening and zero de-noising, but that's not what I've been finding here for a year and a half.
However, I agree with your points, in theory. Practice doesn't follow suit, unfortunately.
Yes, these work beautifully for X3F files taken with older Foveon sensors (as I've often indicated here, and supplied images for controls), but I've been asking to fix images captured with the 5 camera models that use the Merrill series sensors. Those exhibit these problems.
Affinity Photo sees so many frequent updates, and has an embarrassment of conveniences - it's fantastic. I've been trying to make a permanent switch to AP for my workflow, but I am still losing out on some of the biggest advantages that Foveon can provide.
Thanks so much!
-
Thanks so much, @Mark Ingram
I have no problem with issues and setbacks: I'm a developer too, and many years ago, ran a Fortune 500 Customer Contact Centre for a few years, so I'm familiar with the challenges of both diverse backlogs as well as how to properly support diverse users too. I really appreciate your frankness, and am happy to support the efforts with testing if it could make things easier.
It's OK if it takes a long time to fix, as long as there's a plan in place and appropriate levels of communication. I think my biggest ongoing challenge has been the client communication I've received from support, from Day 1 as a customer (in fact, during my trial period too). The only constructive help I've received has been from speculating users, and while that's occasionally invaluable, they are certainly not the authoritative voice of Affinity. That authoritative voice of Affinity support (at least to me) has been vague, evasive, contradictory and even downright manipulative at best.
At this point, I think it would be best to deal directly with someone in development, if you might be able to appoint someone. I appreciate fully how that can be a major productivity interruption, so I will accept much longer response turnarounds, and will minimize my communication to constructive input, to respect their efforts.
This is incredible news about some progress on the Mac platform, so big congrats. I'll be patient and supportive, even if the forward movement is glacial, as long as I can minimize my friction with unexemplary product support.
-
I'm afraid it's not resolved. One tiny bit. In over 18 months.
I have tried what you suggested long ago, to you, with posts showing it doesn't work. The Devs at LibRaw have pointed out that they are providing independent colour channel info to Affinity Photo, but, however people try to process those images into BW (even as has been incorrectly assumed and proposed now as the solution, with zero validation, and I might add), Affinity Photo is doing something bad to it. Affinity effectively is getting good data, but not using it properly.
That's why I made all these dozens of posts for a year and a half, and my posts keep getting shut down, re-edited or moved to somewhere irrelevant.
A good support site ensures the problem is resolved with the OP before closing it: not based on false assumptions or increasing inconvenience or fear of dealing with it head-on.
I apologize for my anger and frustration, but I but after dealing with so much poor handling for so long, it's bound to be a human response.
-
Tried the remaining referenced example images, comparing the most recent non-beta Affinity Photo (1.8.3.641) against the newest Affinity Photo Beta (1.8.3.674) . I tried a few random others too.
OBSERVATIONS
- I haven't found any X3F file that won't open in the newest beta, though my tests haven't been exhaustive. That's a really good sign.
- The images open with possibly slightly higher default exposure & lower contrast (I think), making them immediately discernible most of the time. Previously, most X3F were treated as if the log/linear setting was reversed, and you had to do a lot of work just to begin seeing what the image contained.
- I also found that the histograms in the newest beta are often less 'spiky' (interpolated?) than the last production version.
- An interesting (but non-impacting) observation is that when you first open Merrill images, the metadata below the histogram (pixel count, Std. Dev, etc.) temporarily shows a count of 240,000 pixels for 20-60 seconds, then increases to the RGB-based total (adding the cumulative R, G and B layers for each overlapping pixel, to arrive at a 'total'). It seems some of the default processing continues for a while after displaying the initial image.
- In the majority of images, the default colour accuracy is far better than before, also helping the user by getting things a fair bit closer 'right off the bat'.
- BW images still open as colour, but are far more neutral now, and if you toggle the 'BW' setting (in the Development Personae), the default setting is significantly improved and more recognizable.
- If you (for example) remove the red layer (lowest and noisiest) in the Development Personae, to just use the cleaner Blue or Blue and Green layers, some artefacts still appear, and the noise isn't reduced.
SUMMARY: Key Improvements Versus Original Problem Request
- BW Images still open as colour: NOT RESOLVED (1.5 years & counting)
- BW Images still not aggregating component RGB layers to reduce noise (i.e., R50%+G50%+B50% would give Grey 50%, and sum those RGB values to provide real sampled noise reduction, as opposed to employing arbitrary & lossy noise reduction): NOT RESOLVED (1.5 years & counting)
- BW Images still cannot use or remove one or two of the component colour layers (e.g., keep Blue or Blue + Green layers, to eliminate noise from the Red layer), without introducing artefacts: NOT RESOLVED (1.5 years & counting)
SUMMARY: Key Improvements That Were Not Originally Requested
- X3F images that would previously open, and would not open in AP Beta v.1.8.4.665, can be opened again.
- Default exposure and colour correction vastly improved versus all prior AP Production and Beta releases.
- The application now creates less friction and is more intuitive than was the case previously, for Sigma/Foveon users to process their images .
Great work in getting back on track very quickly!
-
AP Beta - 1.8.4.674 was able to open three X3F files taken with two different sensor cameras.
I haven't had the time to test the full variety of sample images I tried earlier (they are mentioned above in this thread), but this is good news, and I wanted to pass along the preliminary testing status at my earliest opportunity. I will test the full set later and update this thread.
Thanks!
- Chris B and Mark Ingram
-
1
-
1
-
16 hours ago, Joachim_L said:
"...IMO Serif should concentrate on all open or non-locked or best documented formats to make them work without problems..."
Like Adobe's most-proprietary-of-all formats and methods and naming conventions, I suppose?
IMO, Corel, like Adobe, 'own' certain industries, and the only way to gain market share is to be better, and work with their content. Eventually, new content will be developed on Affinity, and content collections will use the Affinity format(s).
I've used Corel Draw Graphics Suite since 2.01 (skipping some versions along the way, but owning most), and would like to switch to a better integrated suite, but haven't found it yet, because it will need Corel support. Designer Publisher seem promising, but you can't walk away from decades of content and service providers with workflows using Corel. If you've got a significantly better suite, you can still 'win' in the long run, but it will take 15+ years instead of five to do so. It's a business decision, and it seems 15+ years for this market is desirable for Affinity. I wish it was otherwise, but they can make their priorities.
-
Here's a sample everyone can use for testing, taken with the older Sigma (Foveon) SD-14. X3Fs from this sensor normally open quite well in the previous Affinity Photo beta & production releases.
Whereas now, even trying to open this very benign X3F file will make the latest beta (v.1.8.4.665) Crash To Desktop. This sample image should still open in other AP beta & production releases, as a control, and if you care to compare Windows logs.
I think that the reason for modifying the already stable AP X3F handling was to improve the quality of X3F's taken with Merrill series sensors, because for just those X3Fs, AP beta & production do a rough job of extracting tonal range, reproducing colour, and introduce a lot of noise if exposed in any way except perfectly. Whatever changes were made to improve that also seem to have affected the earlier Foveon sensors too. Note that there's two later Sigma/Foveon sensors both called 'quattro' (APS-C & APS-H sizes), and I can't attest to how this beta version handles those cameras.
PS - Remember to turn off all noise removal & sharpening.
-
3 hours ago, Uwe367 said:
Yes, @Mark Ingram
Thanks very much.
To summarize my OP, I tried opening X3Fs in AP beta via AP itself, and Windows Explorer.
I tried opening X3Fs using the two most popular resolutions.
i tried opening X3Fs taken in colour and BW.
I tried opening X3Fs taken with two different Sigma/Foveon camera models (that use different sensors).
Every single X3F begins opening in AP beta , then abruptly closes with no error message.
Hope that helps!
-
Really excited to see the activity supporting X3F files: thank you immensely for all these efforts.
I think there's been a small oversight in packaging the 1.8.4.665 Photo Beta, because when you open an X3F file, it immediately crashes to desktop (even before fonts are loaded, etc.). As a control, I also retried the most current non-beta Affinity Photo (1.8.3.641), and that can still open X3F files without crashing out.
I tried this new Affinity Photo Beta using X3F RAW images taken using:
- Max resolution
- Low resolution
- B&W
- Taken with a Merrill sensor
- Taken with an older SD14 Sigma.
I tried manually browsing and opening the varied test set of files from within Affinity Photo, as well as using Windows Explorer's "Open with..." and choosing both 'Affinity Photo Beta' and 'Affinity Photo'.
The issue is consistent for all these (above) X3F files opened with this newest beta.
But even with a CTD, I'm still ecstatic for the developer attention after all this time.
-
The good news @Coldix is that the Devs are apparently working furiously on improving the Merrill RAW support, and (fingers crossed) were last seen hustling to summon one big collective push hard enough to send an email to the Devs at LibRaw, the folks who manage the libraries used to import RAW files into Affinity Photo. They'd probably get to that point soon enough: it's only been a year and a half since I posted it, and about a year earlier since others posted it, so it will probably be any coming year now. In that fevered interim, I reached out on their behalf (because let's face it, sending emails can get pretty complicated), and the folks at LibRaw felt unequivocally that this issue has nothing to do with them, and that the resolution is within the scope of the Affinity Photo team. More time saved!
The better news is that unlike other Customer Support and Delivery teams which waste their time doing things like fully measuring the issue, isolating the root cause and evaluating the effectiveness of different approaches, and especially all that time-squandering communications with their customers providing status updates and next steps, with Affinity, things are way more efficient and we don't need to worry ourselves about any of those frivolities.
We need to trust that they are making good progress all these years, and must be diligent in doing our part to keep upgrading our Affinity Photo versions in the interim. I have been told to stop bothering them with requests about this, so a heads up that you should probably not complain or make any further requests concerning Foveon X3F Merrill RAW support.
Let's keep our fingers crossed!
When we all aim for mediocrity, we help flatten the curve!
AP: Develop - Clipped Tones: Affinity-sourced explanation
in Affinity on Desktop Questions (macOS and Windows)
Posted
Thank you so much, James!
This was precisely the kind of high level advice I've been hoping for. Yes, that made perfect sense and now I understand it. I see now how a creative/pragmatic balanced choice can be made when that occurs, and I will experiment with temporarily moving to a wider colour space and then play with reining the rogue colours into a more common space, or using a combo of adjacent factors to shoehorn things back into place. Bookmarking this for sure! You generously even threw in some bonus ideas. 😀
Very kind, especially amid the flurry of activity surrounding the new launch, but so very much appreciated.
Hope the weekend coming up turns out just as you'd wish!