Losing all benefits of Sigma (Foveon X3F) Merrill BW benefits

One of Foveon's sensors used in five different camera models:

  • SD1
  • SD1 Merrill
  • DP1 Merrill
  • DP2 Merrill
  • DP3 Merrill
  • 

doesn't permit the inherent BW quality advantages normally provided for these cameras when using LibRaw. As an example, BW images only open as colour images in LibRaw.

This issue was escalated to the LibRaw dev team by the Affinity (Serif) devs about a year ago, but I couldn't find it here, so I am raising the issue again in the hope of a solution.

The above sensor has three layers of overlapping sensels for the same three Cartesian coordinates (no CFA pattern is used). In other words, for any given X,Y sensor location, you can obtain all RGB approximations without needing to apply any form of demosaicing. Within this physical silicon sensor, the Blue layer is on top, followed by Green, and the Red layer is lowest: this means that the Red layer is prone to the greatest noise, similarly to someone diving deeper into the ocean, and finding that the Red part of the spectrum has the hardest time penetrating the medium.

For many years, this layered sensor topography has delivered a great advantage for BW photography: you can add the layers to obtain a relatively panchromatic spectrum for every single sensel point (again, no demosaicing required). Since these sensors also feature no antialias/low-pass/blur filter, they not only can skip that demosaic step, but they can also forego all sharpening, and because three separate sensor captures are used (no pixel shifting or multi-exposures), you get benefits of sharp exposure averaging, which means more accuracy and smoother output. When factoring all these advantages together, the output is just like one obtains when using a Monokrom or a specially modified sensor (one where the Bayer and Blur filters have been removed), and in fact, usually better.

There's a few ways to do this when opening a BW Sigma/Foveon RAW image (X3F format):

  1. Treat the image as panchromatic, and add together the counts for each sensel's three RGB layers, for a linear brightness, almost like CMOS binning, and also providing triple exposure averaging.
  2. Do similarly to the above scenario, but permit independent adjustment of each RGB contributing layer (i.e., when simulating BW filters: to obtain an amber filter effect, include greater portions of Red and Green, but less Blue layer).You get more artistic control, at the expense of some exposure averaging.
  3. The least desirable method, at the expense of forcing the spectral response of always using a Blue filter, only uses the Blue layer sensel counts: you miss out on the benefit of exposure averaging from the other two layers, but at least you are using the top-most (least noisy) layer.

I am not able to do any of these three methods using LibRaw: something happens to them during import that throws away that Foveon goodness, making the images look harsh. I have been pursuing this for well over a year with Affinity, but they assure me that the issue is entirely with LibRaw, and since several camera bodies share this same sensor and experience the exact same problem, I am hoping a common fix can be made to let these models behave more like other Sigma/Foveon sensors. For example, I don't have this LibRaw issue with other Foveon sensors (such as the one used in the SD14 camera).
Thanks!

AttachmentSize
Image icon AffinityPhoto, using LibRaw247.33 KB

Forums: 

I can’t understand what kind

I can’t understand what kind of additional support you require from our library.

LibRaw provides access to RAW data for calling application (e.g. Affinity). Calling application is responsible for this data interpretation and processing (e.g. channel mixing if one want to treat Foveon image as BW).

-- Alex Tutubalin @LibRaw LLC

Also, you wrote:

Also, you wrote:
> This issue was escalated to the LibRaw dev team by the Affinity (Serif) devs about a year ago

Sure? Never heard of something like this

-- Alex Tutubalin @LibRaw LLC

Thanx.

Thanx.

I still do not see anything that should be *fixed* on our side (hope Affinity postprocessing is own, not demo code provided by our library)

-- Alex Tutubalin @LibRaw LLC

Affinity Photo & LibRAW combined import issue

deejjjaaaa: yes, you're right, that link was one of about 20+ ongoing posts since December 2019 on the Affinity Photo support forum.

Alex: I apologize, as I can only trust what the authoritative people each tell me, and Affinity (as clearly as they seem to be able to) say they have escalated this to LibRaw, and that it is a LibRaw issue, having nothing to do with them. Pretty well the same as LibRaw feels it is not in their power to remedy this, but rather Affinity's.

Since I seem to have a "he said - he said' issue, would you be kind enough to provide any constructive steps to isolate whom I can work with to resolve this?

There's a good number of users for these 5 cameras with the same issues, and since this sensor's image processing works similarly to prior models, it might hopefully be something reproducible. I've lost nearly a year and a half unsuccessfully trying to obtain support on this one issue from Affinity, so anything that 'moves the needle forward' will be hugely appreciated!

All my best,
DLJ

This whole thing doesn't look

This whole thing doesn't look right. Raw converter developers are supposed to open an issue with us if there is a bug in libraw raw data decoding. I don't see such an issue re Sigma, including opened by the Affinity team. That means the ball is in their court.

Your request doesn't make it clear what needs to be fixed on our side. We deliver the raw data, the rest is up to the raw converter programmers.

--
Iliah Borg

Agree it doesn't look right: the images or resolution process

Again, my apologies Iliah.

I'm just a user stuck with a long-outstanding issue, trying to be as supportive as possible to reach a resolution, even if that's a kluge I need to incorporate. I will do whatever it takes (short of changing the camera system, or having to use LightRoom). I haven't gotten anywhere in a frustratingly long time. Anything constructive you can provide will be hugely appreciated.
Thanks!

Dear Sir:

Dear Sir:
Without clear communication from Affinity we can't help, I'm afraid. We simply don't understand the issue they are having.

--
Iliah Borg

Trying to demarcate issue handling...

Thanks again, Iliah.

In the interim, and for the sake of progress, I will assume that the LibRaw library permits opening an X3F file from the indicated cameras, and provides Affinity the option to request linear or log brightness levels for each RGB channel, including the ability to not apply any demosaicing, sharpening or noise-removal.

That would explain how assembling a 'monochrome' image is entirely up to the raw developer.

In the only descriptive observation I have been able to obtain, Affinity indicated that

"...following one of your previous forum posts, and according to `LibRAW`, your images are colour images.". With no other elaboration, they have confirmed that they know exactly what the problem is.

I will ask Affinity to reach out again.
Much appreciated.

Libraw just delivers decoded

Libraw just delivers decoded raw data to prosessing application. Processing (e.g. demosaicing, white balancing, channel mixing, etc, while demosaicing is not needed for Foveon data) is performed in calling application (e.g. Affinity).

LibRaw contains some postprocessing code (derived from dcraw), it is not intended to use in any professional-level application, this is mostly 'proof of concept'. We do not have any plans to change LibRaw postprocessing code.

Your demarcation is essentially correct.

-- Alex Tutubalin @LibRaw LLC