Jump to content

Wumpus

Members
  • Content Count

    81
  • Joined

  • Last visited

Everything posted by Wumpus

  1. 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!
  2. 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!
  3. 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. SDIM5606.X3F
  4. 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.
  5. 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!
  6. Yes, thanks @deejjjaaaa it seems that some Affinity customers are also stuck in a "he-said, he-said" problem-ownership conundrum. Other points in summary: Affinity has confirmed that the BW images open as colour, and that they otherwise are fully aware of what we're asking for. LibRaw has essentially confirmed the demarcation between their library and the Affinity application's use of their library. They indicate that the issue has nothing to do with LibRaw. I raised this issue during my trial license, and having challenges at that time getting tech support on the issue, I bought a license, on the assumption that I might then begin receiving proper support. That was nearly a year and a half ago, and I keep raising the issue, and have been asked to stop doing so, but am repeatedly forced to resurrect the requests in light of inactivity. When my post's scope of inaction began to draw attention to that fact, one of the posts concerning a current production version was partially consolidated with other posts, and re-filed under a deprecated beta version thread, where it would attract an appropriate amount of attention. Now this time around, a mid-timeline post happening to include the only partial success to date, was re-sequenced to appear as if it was the OP/first post: in that post (in it's new context), it appears as if the majority of the problems have already been resolved, and so also doesn't warrant much attention. It doesn't instill a great deal of confidence in the process, but I will wait to see what actions are being taken, and, as requested previously, hope that there will be some form of update communication posted, sufficient for customers to understand what has newly transpired, and some upcoming approaches and timelines. The product has proven impressive in ongoing updates and technical scope, but speaking as someone that ran a contact centre, I think some gaps remain for the problem resolution methodology.
  7. Thanks @Chris B and @Mark Ingram I reached out on Affinity's behalf to the LibRaw devs, and they cannot find a single communication with this issue raised to them by Affinity, so perhaps Affinity's request got lost in the mail. They also felt that for this issue, they wouldn't be the responsible party to undertake it. Therefore, I'd like to suggest that continuing to wait for new information might be like Waiting for Godot, and only beneficial for elements of our self-reflection (but not necessarily for correcting this issue). I'd really love it if we could wrap up this tech support issue before we hit the year and a half milestone. Please let me help you to help me (and all other users of those camera models sharing the same sensor: SD1, SD1 Merrill, DP1 Merrill, DP2 Merrill, DP3 Merrill) Give me some constructive steps to isolate where or how the problem is occurring. We can do this! As you say the Affinity dev team is fully aware of what I am requesting, it would be great if they could clarify what our blockage is, so that we can work together on resolving this. I remain supportive to help conclude this long outstanding issue. Just one of many ongoing threads, pertaining to this issue...
  8. Thank you so much @Chris B! OK, I am going to assume from your response that "...we have reached out..." means that someone on the Affinity Dev team contacted LibRaw (Sigma wouldn't be of help) about the bad Merrill BW RAW demosaicing. My psychic hat's batteries are dead, and so I cannot know whether that is what actually happened, and that's why I was forced to keep asking for this unfathomable length of time. While this response totally relies on all my wishful assumptions holding true, I finally have a sort of answer, so that's monumental progress, and dearly appreciated (seriously). A good take-away from all this is for Affinity to clearly communicate the status of issues with its customers. I ran a Fortune 500 call centre for a few years, and so learned a little about that, and am happy to share that and other ways to improve response time to shorter than 1 year. That would have saved everyone a great deal of time & effort and reduced client friction. I know it's not your own fault, so please don't take it personally, but Affinity does still have a lot of serious support issues to work on. Have a great evening, and thank you very much again.
  9. Yes, I appreciate that the dev team all knows about this, and they have identified it as a LibRaw issue, and then the issue just died in terms of support at that point. No one from Affinity will notify LibRaw that there is an issue, and so it will never be handed-off and get resolved by LibRaw. Since months passed with no Affinity notification of any form of action, I decided to create the lightest-effort plan of action I could request: could Affinity please notify LibRaw. That's all I'm looking for. I haven't enjoyed posting these probably as much as Affinity hasn't enjoyed reading them for a year either. I'm just trying to motivate to the point of action, then I'll gladly stop. Thank you, and my apologies for persisting in my quest for product support. Incidentally, this isn't anywhere near all the posts regarding this issue in this thread, but please don't bother consolidating the rest. One of the earlier ones pertaining to the same problem, where I thought it might be a weird demosaicing issue (which it now sounds like it is) is linked below. At the time, I was trying to obtain pre-sales support, but couldn't get any, so I subsequently bought the product thinking I might then be supported by Affinity:
  10. Forcing BW RAWs to convert from colour to BW in Affinity Photo for one full year now, for all production and beta versions results in severely downgraded noise, detail and tonal range. Camera bodies affected: SD1 SD1 Merrill DP1 Merrill DP2 Merrill DP3 Merrill´╗┐ Just trying to keep this topic alive after a year of continual requests. Please see the significantly reduced ask (in red) as of last Fall. I basically would just like the devs to register this problem with the LibRaw team. It has long been confirmed by Affinity to be a problem. No delivery required, other than filling out a form. Thx very much
  11. Thanks so much, @DWright The cameras with the problem all have "Merrill" in the title, plus their predecessor model, just called the "SD1": they all use the identical sensor, and have the same output, but slightly different firmware. That comprises around 5 or 6 cameras. I personally tested it with my "SD1 Merrill" (a re-issue of the original SD1), as well as my "SD14", and some different Merrill user's provided images. My SD14's images behave very nicely in AP, but all the Merrill-type sensor images exhibit the same problem. HTH
  12. BW Images still open as colour, and when manually converted to BW, they lose all their Foveon benefits. There's two methods to obtain BWs from Foveon RAWs, and neither of them work in AP. Images taken with the Merrill series cameras are normally able to deliver BW images without the mushiness of a CFA (colour filter array, such as Bayer), or the heavy resolution loss from an antialias filter, like with the a Leica Monokrom, yet are not prone to strong aliasing artifacts like many other cameras. All test images were captured in BW, latest camera firmware, and open properly in some other applications as BW (however, some LibRaw demosaic engine apps open them as colour, suggesting LibRaw as a possible element for the problem. Note however, that digiKam which uses LibRaw 1.19 builds these image thumbnails correctly in BW, and it is configured not to extract the embedded jpeg - it is building a downsampled version of the raw). Forcing BW RAWs to convert from colour to BW in Affinity Photo for the nearly 9 months of production and beta AP versions results in severely downgraded noise and detail and tonal range. How can I support Affinity support getting the issue posted to LibRAW's devs, so that it gets added into their mix of stuff 'in the queue' to be prioritized? I'd really prefer if it had the gravity of a respected LibRaw integrator (Affinity) verifying that it's not some lone user that hasn't done any due diligence. As well, the LibRAW folks might not otherwise appreciate that this affects all Merrill sensor Foveons (not all Sigma cameras, but a large percentage of the current user base).
  13. +1 That would be convenient. Additional +1 if the docs could be expanded to explain what a "Clipped Tone" is, in the context of Affinity Photo.
  14. Thanks so much for testing this, @Mark Ingram How can I support getting the issue posted to the LibRAW devs, so that it gets added into their mix of stuff 'in the queue' to be prioritized? I'd really prefer if it had the gravity of a respected integrator (Affinity) verifying that it's not some lone user that hasn't done any due diligence, and also, the LibRAW folks might not otherwise appreciate that this affects all Merrill sensor Foveons (not all Sigma cameras, but a large percentage of them). Happy to assist. DC RAW engine doesn't have the same issue.
  15. BW Images still open as colour, and even if manually converted to BW, they lose all the Foveon benefits. There's two methods to obtain BWs from Foveon RAWs, and neither of them work. Images taken with 1:1:1 Foveons (such as those with the Merrill series sensors) are normally able to deliver BW images without the mushiness of a CFA (colour filter array, such as Bayer), or the heavy resolution loss from an antialias filter, like a Leica Monokrom, yet are not prone to strong aliasing artifacts like other cameras. All test images were captured in BW, latest firmware, and open properly in many other applications as BW (however, some LibRaw demosaic engine apps open as colour, suggesting a possible source for the problem, for someone within Appian to register this bug to the LibRaw community). Forcing BW RAWs to convert from colour to BW in Affinity Photo for the last 8 months (all production and beta versions) results in severely downgraded noise and detail and tonal range. Thx.
  16. BW Images still open as colour, and even if converted to BW, lose all the Foveon benefits. There's two ways to obtain BWs from Foveon RAWs, and neither of them work. Images taken with 1:1:1 Foveons (such as those with the Merrill series sensors) are able to deliver BW images without the mushiness of a colour filter array, or the heavy resolution loss from an antialias filter, like a Leica Monokrom, yet are not prone to strong aliasing artifacts like other cameras. All test images were all captured in BW, latest firmware, and open in many other applications as BW (some open in colour, and two of those use LibRaw). Manually forcing them to convert to BW in Affinity Photo for the last nearly 8 months (all production and beta versions) results in severely downgraded noise and detail and tonal range.
  17. Just a <1% chance thing to point out when I was burned by mysterious behaviour with Tiff's. It turned out that Microsoft changed the compression format that the tiff was using with something Microsoft preferred. It did this while it was carrying out its thumbnailing service (updating the Windows OS thumbnails for the concerned folder: nothing to do with the tiff format, except that the Tiffs were all recompressed). Because some files were fine for a while, then suddenly seemed 'broken' to other apps (yet behaved 'better' in Windows), I discovered what was happening and confirmed it with Microsoft. Probably unlikely, but just want to suggest that it could also be something unrelated that you don't even expect, messing with your files. Some apps will take liberties with your files. There's a few utilities that let you look at the full file structure, including EXIF and other metadata, and identify what each set of data signifies.
  18. BW Images still open as colour, and even if converted to BW in AP, it loses all the Foveon benefits (not very usable). There's two ways to obtain BWs from Foveon RAWs, and neither works. This has been occurring for six months of production and beta releases, and is not a newly reported issue.
  19. I found the drivers much more linear by setting them to a positive # for the curve, as shown in the screenshot. The responsiveness was really nice, actually. Notice I actually have Windows Ink enabled (I had thought it was disabled).
  20. Offsite so can't check until later, but found a prior post where I mentioned my model ( Huion 610 Pro v2 ). March 2019 Designer Beta forum It seems my model is different from yours, but i think the 1060 Plus was around the same timeframe as mine, so there's bound to be overlaps or similarities. I think our models both had 8192 levels of pressure, higher per second flow rate, and batteryless (if I recall: I'm pretty sure I had been looking at both models before I made my purchase). If I understand correctly, your question is about pressure 'transition' (curve?): it sounds to me like its' not exactly linear, but more like a formula one gas throttle? I will check mine out, but I don't recall any kind of concern once I got mine settled, but I think that might have been an issue for me when I started out using the wrong driver, and it was always jumping from zero to max pressure, and also my flow rate had been really slow and laggy. Make sure you have got the correct driver, and you might need to play with Windows Ink or Pen & Ink settings. I will try to verify but might not have a chance for a day or two.
  21. Still no change for current 1.7.2.414 beta. In fact, BW images still missing all quality benefits, and still an outstanding issue for all versions since January 2019. Nudges, bumps or escalations all appreciated.
  22. @Bobi and @Gnobelix I'm using this too, and have had great support from Huion, and it works well (except I haven't found out yet how to apply the tilt to any functions, but that's not important for photo editing, IMHO). The build quality was superb, the feature list is mind-blowing, and while Wacoms tend to be more broadly tested from developers (I have had 3 in the past, all bought as new) and after a while they just stop fully working. I wasn't feeling the love, and didn't enjoy repeatedly paying a premium price for something that always works very well until the day it doesn't (with no warning). I took a gamble on Huion, and it's only been about 8-9 months, but the construction and materials are quite high, with far greater functionality than anything in the price niche from Wacom. The drivers are definitely not as intuitive or have as clean or elegant or modern a user experience as Wacom, but they work, and you can master them if you invest a bit of time and checking other tutorials (lots on these models). They are gathering momentum in the marketplace, and again, the support is almost a white glove experience (other vendors take note). The second downside is that (this is from memory, so this might be off a little): there was a Huion 1060 II model, and a 1060 PLUS NEW model, and a 1060 II Plus model, and I had carelessly grabbed the wrong driver from their site and only had about 10% functionality. The different (but similarly named) models hardly have any overlapping support, so you need to be super careful about getting the exactly-named drivers (flip over the tablet to read the tiny model name). Maybe it's due to a right-left language or something in the translation, but it seemed to me, to be terribly easy to make that mistake, but once pointed out and having installed the correct driver, all was good. My prediction is that they are going to eat a lot of Wacom's marketshare, who have (IMHO) been sitting on their hands counting revenues for too long. All the power to Huion, even if the result is just to get Wacom to properly respond to their user base. I receive no direct or indirect benefit from this commentary, from either Wacom or Huion.
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.