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.
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:
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…
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 Adding Support for New Raw Formats - RawPedia. 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 How to create DCP color profiles - RawPedia 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.
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 @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).
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 ?
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)
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
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)
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.
because I’ve no clue what you just say…
