BTW, @eobet , what is the computer in the foreground? It resembles a Commodore C64, but that only has 4 function keys, a 4-row keyboard (+space), and the power LED looks different, too:
Fairly good result. What’s your approach to the compression currently like?
How about a “new” Commodore C64?
Have fun!
Claes in Lund, Sweden
3 Likes
I analyse the image, finding the max C (of LCh) for each out-of-gamut pixel. I then take the max. of the C_actual / C_at_gamut_boundary, and apply a curve (Tone Curve Math Question - #6 by Thanatomanic) that gradually scales the C values so they all get inside the gamut. For L, I use the same kind of curve, after determining the max brightness; the shoulder is chosen such that the brightest pixel’s L value ends up just under 1.
The code is here, but it’s not written in the style used in image processing. 
I tried to play it (type)-safe, didn’t care about performance. You’ll probably find it waaaay over-engineered (as it is).
2 Likes
My Hungarian is rusty, but jól látta! 
It’s a Mini-ITX case based on the original Commodore injection molding tools. Someone in the UK bought them and made modifications so you can fit modern hardware in them (mine is one of the last made in the UK too, if you order one today you’ll get made in China). Instead of putting a PC in there, I put a in FPGA system (a guy in Spain makes a Mini-ITX kit) so I can run any computer/console from the last 40 years with everything from casette audio input to modern network support, both modern USB and old input support and both modern and old video output support as well (you can see a bit of a pro video CRT monitor in the background that I use with it for that real old school feel).
Sorry for the long and nerdy answer, but since you spotted nerdy details, I thought you might want some back! 
(Translation for Photography nerds: Imagine a hobbyist hardware kit camera that could take any lens from the last 40 years and simulate any sensor from the last 40 years, and optionally shoot both digital and film.) 
5 Likes
@Jiyone thanks for sharing your xmp file. I tried to work out what made your edit so good. It seems that the guided laplacians for the highlights reconstruction module was the main secret. I have personally never had any success with this option, but I see you turned the threshold down and when I moved this slider, suddenly I too got a good result.
2 Likes
Yes the laplacian hl reconstruction is the right module to use in that case to smooth highlights.
I had to lower the threshold because I saw that highlights were clipped on the histogram (and in the picture obviously) but they were not selected by the mask.
Then I choose the best suited diameter, and change the iteration number until desired results.
Excuse my ignorance … where did you find the laplacian hi reconstruction.
Looking at the .xmp I only see the inpaint version!
OK … I see it now in the filmic operation …
It was in the one I downloaded…make sure you loaded it…
It’s only available for Bayer sensors (that is, it’s unavailable for Fuji X-Trans). Most of the time it’s not much good, and is very slow.
https://darktable-org.github.io/dtdocs/en/module-reference/processing-modules/highlight-reconstruction/
The one in filmic is not really about recovery, but rather about ensuring a smooth transition. It does not know what pixels are clipped at the sensor level; rather, it uses the filmic white relative exposure as the threshold.
https://darktable-org.github.io/dtdocs/en/module-reference/processing-modules/filmic-rgb/#reconstruct
2 Likes
Strangely it creates quite an effect with my Fuji X-Trans!
There seems to be a confusion. There is the guided laplacians method in highlight reconstruction, which is not available for X-Trans. You yourself wrote:
To that I responded by pointing out that the method is:
- not available for X-Trans; I even provided the link to the documentation
- different from the method in filmic.
And now you say ‘it’ (which from the context (It’s only available for Bayer sensors) one would interpret as the guided laplacian) creates ‘quite an effect’. It does not. Here is one of your X-Trans images, for which guided laplacian is not available:
Here is one of my Bayer images, for which it is:
Again: the reconstruction operation in filmic does not deal with clipped sensor data, you can even use it with JPGs. All it cares about is the white relative exposure.
If I recall it was disabled in the filmic instance used by @Jiyone , rather enabled but the threshold was 3 EV so enabled… as @kofa points out there seems to be a bit of confusion sprinkled in the comments…
I saw the guide laplacians option used in the highlights reconstruction module. I did not check out filmic. The guided laplacians in my hands gave a pleasing result if I lowered the threshold. I did not tweak any of the other sliders that the OP used. Just the thresholds was important for me. This is the first image that guided laplacians has ever worked on for me and only when thresholds was adjusted.
1 Like
About the laplacian method in HLR module. As i see it, nicely working on smaller specular highlights, no good for flat and somewhat larger regions. Increasing radius & iterations helps just in some cases …
Yeah, I didn’t mean to badmouth the Laplacian method; but ever since inpaint opposed (and segmentation-based) have appeared, I use it very rarely. In the past, in a large part due to darktable having limited highlight recovery, I tried to avoid highlight clipping completely (except for specular reflections). With the new methods, a bit of clipping, e.g. in the sky, often goes unnoticed. I often had colour bleeding with the Laplacian; the new methods seem to be more resilient to that.
1 Like
I too mainly use the inpaint opposed methods, but with this image the laplacians gave a very pleasing result when threshold was reduced. However, I hate trying to fix up clipped highlights with any method. I would much rather try and avoid clipping in the camera, but sometimes it may not be possible.