GFX 100S support

Hi folks

I just got my new camera (GFX100S), and try to help RT to support it (To be honest I’m using darktable and Capture one).

Knowing GFX100S use the same sensor than the GFX100, I try to modify the camconst.json but it’s not working. RT don’t say it’s don’t know the camera but the render end up with a full black windows.

With some similar patch on darktable, it was able to show the image with some problem with exposure but at least got something.

I already upload some raw file in the https://raw.pixls.us/

If anyone need other information/sample/test I will happy to answer it.

Z

Holy cow, those are some big raws…

You might double check the make_model in your added camconst.json entry, as what’s already there for the GFX 100 won’t match the raw file Model tag value of GFX100S if there’s a space between GFX and 100. From an exiftool dump on one of your raws:

[EXIF]          Camera Model Name               : GFX100S

Thanks for the tips. But I already try it, first I use the exact same output as a exiftool file|grep GFX, (so no space), than with space.
Same result.
Each time I restart RT, and remove .config/Rawtherapee and the file.pp3
And yes…it’s huge file.

My hack software uses libraw, and easily it opened “Fujifilm - GFX100S - 16bit uncompressed (4_3).RAF”. But, libraw didn’t have camera color primaries, so I copied the GFX100 primaries out of camconst.json and pasted them into a rawproc colorspace tool, and the image developed quite nicely. Slowly, however, on my 4GB Surface 3 Pro…

Well…if you say so…:wink: because I’ve no clue what you just say…

I just modify the file camconst.json and it’s not working, here the lines I add

    { // Quality C
        "make_model": "FUJIFILM GFX100S",
        "raw_crop": [ 0, 2, 11664, 8734 ]
    },

Hi @zorgtool, I’ll take a look to see why the image won’t load. It might be related to something else than a camconst.json entry.

As for additional camera / color rendition support, please provide the shots as outlined here http://rawpedia.rawtherapee.com/Adding_Support_for_New_Raw_Formats. Please use the 16-bit uncompressed format, but use 7-zip or regular zip to compress the files. Especially for pure white images, you should be able to save a lot of space.
If you own a color calibration target (such as an X-Rite ColorChecker Passport), you can further improve the color rendition of files from your camera. Please read http://rawpedia.rawtherapee.com/How_to_create_DCP_color_profiles and provide the necessary shots.

This patch enables the correct decoding of 16 bit Fuji files, including those from GFX 100 and GFX100S (without space, apparently). The uncompressed and lossless compressed files work, the lossy compressed files don’t. See here for details.
Unfortunately, our nightly builds are not working atm, so you either have to wait for those to be fixed, or compile RT yourself if you need to work with these files right away.

2 Likes

I just rebuild and gave this one a test and it works nicely.

I’m sure you tested it on your box, just wanted to make sure :wink:

Ok. I will try that. Not sure I will able to do the X-Rite thing. I got one indeed, but currently I working only under linux. But I will check that.

Thanks for the support.

If you provide the shots under the proper illuminants (clear daylight and a tungsten lightbulb), then I can turn it into a DCP for you. However, this would really be the cherry on the cake and not strictly necessary. We already have a color matrix from Adobe that we can use and those normally work very well already.

Hi @Thanatomanic

I just did the first part, sorry for the delay.

Here (sorry unable to use filebin, crash everytime)
http://dl.free.fr/siWgcsFQ1

and

http://dl.free.fr/ksPS1PCWa

The first are with Long Exposure Noise Reduction, and the second without.

It’s a bzip2 tar.

Tell me if it’s Ok for you.

Soon I got time I will do the second part.

Z

1 Like

Many thanks, I’ve got the files! I’ll analyze them asap.

Hi @zorgtool, you might have uploaded a wrong set of images for the LENR ON. They seem identical to the ones without (metadata says 0.8 s shutter speed, which is usually too low for LENR to kick in). Could you please check?

Otherwise I have an somewhat interesting observation to make on the other files, in that your sensor seems to have a ‘cool’ spot that saturates a little less than the rest of the sensor (black = 65535, middle of the spot = 65295).

Double s**t…

I will take another serie of shot soon as possible

How did you notice the problem on the sensor ? (just want to check to see if I can ask the brand, even I don’t think that affect the result of the photo) In your opinion can that be a dust ?

Z

I greatly enhanced very small differences in the raw sensor values. It is so far into the highlights and makes up only 0,36% of the entire range of raw values that I wouldn’t be too concerned. It is definitely not dust, because this effect only shows on one of the Bayer channels.
I have no idea who would know more about a possible origin. Do you have the option to change the title of this thread and add something about an artifact? That could attract people’s attention.

So I just upload a new tar. For some super weird reason the file is much much bigger. I don’t know why, I double check the compression doesn’t work as efficient as yesterday…so if you want to check here the checksum of each file
checksum.txt (2.2 KB)
and the download link (900Mo)
http://dl.free.fr/gcYOBPjS6

I also notice I forget to shoot at more than 12800 ISO yesterday, so here the few shoot at more than 12800 without Noise Reduction

http://dl.free.fr/j6JEWO6bV

Thanks for you work

Ok…No I can’t change the subject.

But well if you have time, can you say how you do

Personnally I pretty sure it’s just a flaw in the sensor. But if I’m correct that would be in the error margin where the manufacter don’t agree it’s a problem.
So If I can prouve to them it’s noticeable … maybe I can do something (I doubt that but…who knows)

Z

First part (not sure I done it correctly, new camera is a little pain…).
So I take 2 x 3 shots, first set with «white balance set to auto»
http://dl.free.fr/vvIRdeVCr
and second set with «white balance set to daylight»
http://dl.free.fr/hNYJDNVxW
Each set contains 3 shots (bkt).

Those two set if for the shoot under daylight of the colorchecker

Z

Hi @zorgtool, I did some more analysis of the sensor data. I use Wolfram Mathematica for the analysis - but similar things could easily be done in Python.

Method: I loaded all raw values, determined min and max values and then scaled them to range from 0-1. This greatly amplifies minute differences (usually less than 1% at the very highlight end of the range, so very hard to distinguish in real-life scenarios).

Results for RED channel of the Bayered data per ISO:
Without LENR


With LENR

Results for GREEN 1 channel of the Bayered data per ISO:
Without LENR


With LENR

Results for GREEN 2 channel of the Bayered data per ISO:
Without LENR


With LENR

Results for BLUE channel of the Bayered data per ISO:
Without LENR


With LENR

Observation
The green channel seems the most uniform. The other channels have interesting patterns which are probably caused by the electronic layout of the sensor. If you look closely, the patterns actually shift somewhat along the shots. The shift is rather big, otherwise I would have somehow attributed this to the pixel-shift abilities of the sensor. Now I’m very unsure…
The LENR just introduces noise (dithering?) in particular for ISO > 1250 or 2500.

Conclusion
Despite this, I think I have enough information to update camconst.json with proper white points.

Thanks a lot of those explaination. I will try to digest them :wink:

I will also conduct some real life test to see if I can detect something

Z