More on the SDQH color issues

[Fourbillionyears]

I am having the same issue of wrong colors in the DNG converted file (essentially a pure magenta/violet image). Here is what I can add to what has already been posted:

• My SDQH currently has firmware update 1.02. This yields the incorrect color DNG files.
• Early X3F's from the same camera before the firmware upgrade fail to process. I get the error message:
  error code:1 argument list: [-compress, -wb,Auto,path to file]. The camera is an early one, so it is likely that at that stage it had the original firmware, version 1 (?)
• Files from my SD1 Merrill convert perfectly.

Please let me know if I can be of any help, or if you would like me to send you x3f files of the various types listed above. And thank you for all your efforts in dealing with this maddeningly frustrating yet wonderful sensor technlogy!

Alberto

[evanXA]

Hi Fourbillionyears,

If you are willing to download the repo and build from src this is a really quick hack that makes it appear to work for most images (I've tested it on nearly 100 different images all successfully) This is not a real fix, i don't think the issue is here, but it's just the easy place to add a multiplier.

If you don't want to do that my current workarounds are:

1. You can also use a program like Darktable and in the WB table set the B channel to 1/2 the Red/Green scales. This seems to work as well.

2. Finally, shoot at ISO 400, but overexpose by 1 stop. This gives you a ISO 200 image, and x3f extract works very nicely for anything but base ISO.

Inside x3f_process.c at after this section:

for (color = 0; color < 3; color++)
	{
    scale[color] = (ilevels->white[color] - ilevels->black[color]) /
      (max_raw[color] - black_level[color]);

You will need to add a little bit of logic to scale by 2 if the right camera is selected.

/*Begin Hack for ISO 100 */
double sensor_iso, capture_iso;
uint32_t cameraid = 0;
int ISO_100_SCALE = 0;
x3f_header_t *H = NULL;
H = &x3f->header;

/*Lets find out what Camera we are using*/
x3f_get_camf_float(x3f, "SensorISO", &sensor_iso);
x3f_get_camf_float(x3f, "CaptureISO", &capture_iso);
x3f_get_camf_unsigned(x3f, "CAMERAID", &cameraid);

if (cameraid == X3F_CAMERAID_SDQH && H->version == 0x40002) {/*Only Quattro H and Firmware 1.04*/
	if (sensor_iso == 100.0) {
		if(color ==1) {
			scale[color] = scale[color]*1.2;
		}
		if(color ==0) {
			scale[color] = scale[color]*1.2;
		}
		if(color ==2) {
			scale[color] = scale[color]*0.6;
		}
	}
/*End ISO 100 Hack*/

[rolkar]

Hmmmmm ... good find! Your solution is, of course, strange.
There needs to be some meta data that tells the actual scaling modifiers.
But - anyhow, now we know where to look for the problem.

I assume this is a way of avoiding clipping in layer 2 when using ISO 100, i.e. the most exposure.

BTW - why did you not choose the multipliers 1.0, 1.0 and 0.5 ? That sounds more logical, to only half the layer 2.