Picamera2: jpg vs raw-dng

@Ljuslykta,

I think you mean taking several different exposures and then combining them into a single dng file so that the best exposed pixels are saved in the resulting dng file.

I suppose it could be done but unfortunately I do not have the necessary knowledge.

Digital cameras have options for taking HDR photos. They take several shots with different exposures that are later combined into a single image.

However, the resulting final image is always jpg. If we decide to save the individual shots, they are saved in raw format.

Therefore I want to think that it must not be easy to do the fusion in raw format…

@Ljuslykta - you probably end up with the worst of both worlds! Seriously, the Mertens algorithm is based on already developed imagery, while raw-files are by their very nature not developed yet. This does not match well enough.

I am also on the starting portion of the journey of considering multi-exposure capture.
As mentioned by @cpixip, the algorithm expects developed images, meaning, ready for visual presentation, which is normally not the case with raw.
The drawbacks of using jpeg compressed pictures would be:

  • The limited to 8 bit per channel.
  • JPEG compression artifacts.

In the context of Mertens, and multiple exposure, the 8 bit limitation would be addressed by the resulting HDR output. If using a higher resolution for capture than the final video output resolution, the impact of the JPEG artifacts would be mitigated.
If going purist, one alternative is to produce uncompressed 12bit TIFF developed images from the raw capture, and use those as Mertens source.
I would think that this approach may provide the option to reduce the number of exposures (compared to JPEG) for a similar dynamic range.

1 Like

@Manuel_Angel @jankaiser: guys, your experiments are very interesting!

A few comments…

A raw capture needs a finely-tuned exposure. You need to make sure that the highlights do not burn out (cmp this old post here). In fact, the exposure values chosen in your examples take care of that. You want to have the safety margin as small as possible, because every stop you are underexposing leads to missing/noisy data in the shadow regions. Lowering the exposure duration leads to a little bit of quantization noise in dark image areas; however, as the noise caused by film grain is much stronger, nobody will notice.

The development of the raw image is a two-stage process. You transform the raw color values into “real” color values with camera-specific color matrices. Normally, the .dng-file features at least two color matrices for two different color temperatures. Once you pick a whitebalance (and a corresponding color temperature) the actual color matrix used during development is interpolated from the two color matrices embedded in the .dng. I did not follow the latest steps of the libcamera development too closely, but I think the two color matrices embedded in a HQ camera raw are taken from data/experiments of Jack Hogan. These should be fine for all practical purposes.

The second stage in the development of the raw image is the intensity mapping - both of you employ a noticably S-shaped curve by setting the highlight and shadow values appropriately. In the end, both shadow and highlight areas feature a reduced contrast, compared to the mid-tone range, and that ensures that you still see image features in these areas without highlights buring out or shadows drowning in the dark.

The Mertens-path (exposure fusion) is quite different. The jpgs used in the exposure fusion are created by libcamera based on the tuning file used for this camera. Typically, the tuning file contains more than the two color matrices stored in the .dng-file. Normally, libcamera itself estimates a color temperature and calculates from its estimate the appropriate color matrix. If you work with preset color gains, a fixed color matrix is chosen.

So: already the color processing is different in the two scanning paths you are comparing against each other.

The second stage, namely mapping the linear intensities of the raw image data into the non-linear jpg-colors, is handled again by a section in the sensor’s tuning file, the “contrast curve”. The curve which is used in the standard tuning file is a non-standard curve, leading essentially to a very contrasty image with increased color saturation and reduced shadow and highlight detail. That contrast curve was probably chosen to satisfy the taste of the standard user. There exists a second tuning file for the HQ sensor which features a standard rec709 contrast curve. Jpgs created by this alternative tuning file have a reduced color saturation in the midtones, but better contrast definition in the highlights and shadows.

Whatever is used to produce the jpgs, the exposure fusion algorithm is designed to take data from the “best” image of a region and merge that together into a single output image. This is done in a way taking into account how the human visual system is processing given image data. The result is an image which has image data in every area where at least one of the input scans shows data.

One specific issue with the Mertens exposure fusion algorithm is that usually, the contrast range of the output image exceeds the standard range [0:1]. Adjusting for this reduces the contrast of the image even further. And: it also reduces the color saturation again.

In the end, the output of the Mertens path is more comparable to a log-image and needs to be treated in postproduction appropriately (adjusting contrast and saturation, of example). Comparing the two approaches is difficult and things are constantly changing. The Mertens path is mostly automatic (with appropriate parameter settings), but time-consuming in capture as well as postprocessing. The raw processing path became only available recently, due to software improvements in the Raspberry Pi software offer. It should be much faster, especially if the raw input feature of, for example, daVinci Resolve is taken into account.

Due to its adaptive behaviour, the Mertens approach should provide better detail in highlight and shadow areas; I think in very dark footage, Mertens will have a small advantage over the raw-based path. Whether that is worth the increased workload during postprocessing will probably depend on personal preferences.

The major drawback of a raw-based approach is the limited dynamic range 12bit per channel can accommodate. With a properly chosen exposure value, this will not be noticable for most of our footage. Even with footage where a multi-exposure scan might have an advantage, the film grain of our small format stock covers that to such an extend that it will not be noticable. A grain reduction step which is recommended anyway for such small formats will iron out even these small differences.

2 Likes

@cpixip,

As usual in your posts, the high technical level is impressive.

In my case, I limit myself to using the different formats as a user, but I do not know the internal functioning of each of them, like the driver of a car who does not know how the engine works.

Thank you for sharing your authoritative opinions.

Best regards

1 Like

@Manuel_Angel - here’s something you might be interested in as relaxed car driver:

I took the two raws which are discussed in this thread into daVinci Resolve and checked out how far one can go in this software. First, the result of your scan:

To arrive on this output, I selected “Decode Quality” = “Full res.” or “Project Settings” (that setting does not change much with the resolutions we are working with) and “Decode using” = “Camera metadata” at the “Camera Raw” section of the Color Page:

grafik

Still on the Color Page, I adjusted shadows and Hi/Light, increased the Saturation a little bit and pushed the contrast as well. It is difficult in this image to find a good spot for whitebalancing. I adjusted the Temp-value in such a way that the whites in the bright area between the tree (top-center) have approximately equal amplitude. In total, the color controls have been set up like this:

Now for @jankaiser’s image. Setup for the “Camera Raw” section was the same, whitebalance was adjusted so that the wall above the stairs in the center frame featured equal RGB-amplitudes. Again, highlight and shadows (this time a little bit more than in your image) were adjusted and saturation a little bit increased. Here are the settings used:

And here’s the result:

I must confess I like the direct input of raw-dng files into daVinci more than employing an external program for this. You have all controls available in the Color Page, you can optimize scenes independently (and daVinci can cut for you the whole footage automatically into scenes), you have quite powerful scopes available to guide your adjustments and finally, daVinci is faster than RawTherapee.

This workflow was not possible some time ago, when Raspberry Pi foundation’s software did not create well-enough behaving raw files. Obviously, times have changed.

3 Likes

@Manuel_Angel - still having fun with your image and daVinci.

I adjusted slightly the color grade and put in two nodes in the node graph of the color page:

Node 01 performs a spatial noise reduction:

grafik

and Node 02 a sharpening operation:

This is the result:

Not bad for my taste with a workflow only utilizing daVinci and no additional software…

4 Likes

This result looks great! I am especially jealous of the sharpening. It’s quite a bit sharper without actually looking sharpened. I remember observing this in one of your previous posts a long time ago already (I believe it was a frame with a bus on a road in the mountains). Somehow, I can never quite get this right, and even when I only apply sharpening lightly, it always looks somehow over-sharpened.

daVinci’s sharpening is very sensitive and difficult to adjust. That’s why I perfer to use my own tools for that. The “bus” is such an example.

The strategy is always the same: you always need to reduce the film grain as best as possible, otherwise only the film grain gets sharpened. That is what node 01 does in the above example. Normally, you would employ temporal denoise as well, because it is much more effective on film grain (while you have a spatial correlation wit respect to film grain, temporally, film grain is uncorrelated). Since in this example I only had a single frame, there was no option here for this step.

Once you got rid of the film grain (by whatever option is available), a mild sharpening can be applied. Main controls in daVinci are the radius (stay close to 0.5), and the scaling, which seems to vary the amount of sharpening applied. But I have yet to find a proper documentation about what these controls really mean in terms of image processing…

@cpixip,

The result of the last treatment given to the image has been truly great.

The image has been absolutely unbeatable: vivid colors, well saturated without exaggerations. Detail in all areas and especially what has surprised me the most is the increase in sharpness.

It has been fully demonstrated what can be achieved by knowing what we do and using good tools.

I have had version 17.3 of Da Vinci Resolve installed on my Linux machine for quite some time, though I have never used it.
It is clear that I have to learn how to use the program, although I have a little respect: the user manual is more than 3000 pages.

It seems that taking the raw-dng route and further processing with DaVinci Resolve is a very good option to follow.

However, in principle, I see two problems:

  • Logically, a film will contain very bright scenes and others that are noticeably darker. Scenes with little contrast and others with high contrast. So we can’t just scan the whole film with the same exposure and with HQ camera and raw shots it’s hard to decide the right exposure, we don’t have help like for example with a digital still camera.
  • On the other hand, the consumption of resources is enormous. For a simple 15m Super8 film, we would find 3600 dng files each 17.6 MB, if we scan at the camera’s full HQ resolution. If we were content to scan at the intermediate resolution (2028x1520 px), the size would be reduced to 4.4 MB per frame.

Here is the same image scanned at the aforementioned resolution of 2028x1520 px, in case you consider it appropriate to give it the same treatment and compare results.

Thanks again for your excellent contributions.

Hi @Manuel_Angel - the current version of daVinci is 18.5. And yes, there is a steep learning curve involved. The reason: this is a very professional program and a lot of advanced stuff is somewhat hidden from the average user.

However, there are free tutorials available from BlackMagicdesign and a lot more if you simply search on youtube with “davinci” and the topic you are interested in. I highly recommend to obtain the studio version, which costs around 330 €. For our specific purpose, the temporal and spatial noise reduction features are important to have. The Studio version features also quite a lot of other goodies, like automatic scene detection.

Anyway, here’s the result with your reduced size raw image:

using the same processing path as the previous example. The differences are tiny, if you compare that to the previous result. This might be correlated to the input setting I used:

grafik

The decode quality is only equivalent to the resolution of the project, in my case 1920 x 1080.

The largest film roll I have contains approximately 50000 frames (about 46 min running time @18 fps) - this would amount to about 0.88 TB of data scanning in full resolution. So a dedicated SSD like the Samsung T5(1TB) is sufficient. And that is actually the disk I am using during scanning (both PC and directly RP).

2 Likes

I think that scanning raw might be even easier, in a sense. The following is getting a little bit technical but I will try to keep the things simple and (maybe) short.

The problem arises with the immense dynamic range a normal color-reversal film can feature. A normal camera with, say, 12 bits per color channel simply can not resolve this dynamic. One would need at least 14 bit, preferably more.

One way out of this is to capture several differently exposed images and combining them into a final one. This is the basis of the Mertens exposure fusion algorithm. Or, if you dare so, to create a real HDR from the exposure stack.

Another, alternative way discussed in this thread is to capture just a single raw-dng file and process this appropriately. Advantage are: speed, as just a single capture per frame is taken, and therfore much faster processing.

The disadvantage is that you need to get the exposure right. If you do it right, a raw 12 bit per channel capture will be visually indistinguishable from a Mertens merge.

But how do you set exposure? Well, if you overexpose your frame, you will loose all highlight detail. But there is a simple and sure recipe to avoid that situation. Simply adjust your exposure in such a way that the empty film gate gives you the full image intensity without being clipped. Since anything in the film gate, including transparent highlight areas in your frame, will reduce the amount of light arriving at your camera sensor, that data will surely not be clipped. In fact, since the raw-dng is a linear record of the intensities your sensor is recording, the situation is actually slightly more favorable than with the non-linear JPG as output, as used in the Mertens approach.

The downside of the raw-dng approach is actually hidden in the shadows. They will not be covered as good as it is possible with a multi-exposure approach. Does it matter? Probably not, because of two things. First, shadow areas will show up in your final footage anyway as rather dark areas. A loss of precision will be barely noticable, especially with small format film and its excessive film grain in those dark areas. And, if you employ an additonal film grain reduction step, this step will also take care of the small errors caused by the low intensity resolution in dark areas of your single raw-dng.

I am still in the process of comparing these two approaches with each other, so I do not have yet a final answer on how much the use of a single raw-dng might affect image quality in dark areas. I think that multiple exposures might have an advantage when it comes to severly underexposed images - a thing which happens quite a lot with non-professional footage - and extreme color challenges, like old Ektachrome film stock faded into pink. But again, that needs to be tested.

In summary: if you set your exposure in such a way that the empty film gate gives you full white in the raw-dng without being overexposed, your safe for all of your scans, irrespective of the film material you are going to scan.

2 Likes

Just a quick update. I modified my scanning routine to take simultaniously raw-dng and multiple exposures from a frame. Then I color graded both sources so that they looked more or less identical. I realize now that using full frame raw-dngs puts a quite load on the hard disks throughput- 18 fps @ 18 MB equals 325 MB/sec. So working in daVinci kind of becomes lame - even with render cache and proxies enabled.

Colorwise, both approaches are more or less identical when tuned that way. This mainly required to push the saturation of the exposure fused results from the default “50” to “72” or so. While being overall more or less identical, the exposure fused result had a tiny bit more of brilliance in the mid-tones. The most suprising result was the difference in noise between the raw-dng and the exposure fused image. Will continue to experiment…

In addition to those explained by @cpixip above, I would add that another downside is when multiple scenes in the same film are significantly underexposed. The method to set the range will result in those underexposed scenes be quantified with less bits, and when gain is increased in post, the underquantification will show.

HDR and Mertens multiexposure have the toll of processing time.

A poor-math-man alternative is to do multi-exposure bracketing. Use the method above to set light/shutter for a properly exposed scene. Then, at capture, do an additional (or two) longer shutter captures. In post, if a scene is underexposed, simply pick the alternate frame sequence for the scene, and done.

Another alternative I would like to try at some point is to blend two (dng) or more (jpg) different exposures sequences in Davinci Resolve, instead than using algorithmic stacking (Mertens).

The shortcomings of the well exposed 12 bit dng and/or underexposed scenes, will be complemented by the second exposure blend in resolve. Some curves and nodes should do the trick. Another advantage of this approach is that the blending should also reduce the noise of the resulting image, maybe just a bit, but less.

While these alternative methods require more than one exposure, depending on the film content, it would be a small price for the benefits.

As has basically been said already by @cpixip, you can pretty much expose for the highlights and you should be close enough to be able to fix bad exposures in post. In my experience, this works very well in practice. In fact, I have set my exposure on my own scanner once and never changed it since for probably about 50 rolls of film shot in many different conditions (from dimly lit indoor shots to bright sunlight) and on different film stocks. I was even able to recover seriously underexposed shots, which brings me neatly onto this next discussion.

My particular seriously underexposed shots were so underexposed that viewing them on a projector you can hardly even tell what they show. Yet, with the same exposure I always use, the image can be recovered. I think I’ve mentioned it on another thread, but even if I expose for these underexposed scenes, the image does not look any better than it does using my usual exposure and then increasing the gain in post using the RAW dng files. As said by @PM490, the “under quantisation” is probably there when pulling pulling up the gain in post on those underexposed frames, but frankly, if they are that underexposed, the film itself already doesn’t look great. In my experience, the underexposed film looks worse than the “under quantised” shadows, making the latter more or less insignificant to the quality of the final result.

1 Like

By fixed exposure I mean the same shutter speed, gain, and lens for the complete film. A normal scene would result in the full quantization, meaning blacks would be near zero, whites near full range (4096 for 12 bit), easy to see in the waveform. In a badly underexposed scene, whites instead would be significantly less, some times below 400 (10 times less than normal).

Not sure I follow… How the same exposure (fixed exposure) would work the same for under and well exposed scene and seriously under exposed scene.

The under quantization problems are seen easily in Resolve. After adjusting the gain/gamma, adjusting the lift controls moves the waveform in abrupt steps-like bands, rather than the ultra smooth adjustments typically expected. It will also hinder an accurate color correction of dark areas.

… as indicated above, I continue to experiment with direct RAW-capture. Actually, I have tried RAW-capture for quite some time, but always with mixed results. The raws you could get out of the HQ camera lacked a lot of information necessary for appropriate raw development. This situation has now improved to a point where a picamera2-based raw capture can directly piped into daVinci as well as other software, for example RawTherapee, with good results.

I promoted on this forum for a long time multi-exposure capture and exposure fusion as an easy way to aquire decent captures of old color-reversal film. While exposure fusion gives you quite pleasing results, there are some deficits hiding behind this algorithm. Specifically, the light intensities are modified, as well as the color values. Something you will do in color grading as well. But while you do this in color grading manually, in a guided way, it is done behind the scenes, automatically when utilizing exposure fusion.

Let’s look at an example of a frame captured simultaniously in RAW and a 4 exposure image stack, exposure-fused via the Mertens algorithm:

Clearly, the outcome of the RAW is different from the exposure fusion, in many ways.

[Technical details: The exposure/illumination was set in the scanner in such a way that the empty film gate was at the 83% level of the full 12-bit dynamic range of the HQ camera sensor. That resulted in a level of about 240 in the darkest jpg output (the “highlight” jpg, pictured above). Burned out image areas in the film frame reach only a level of approximately 70% - so nearly 13% of light are eaten away by the blank emulsion of this Kodachrome. Clearly, that is not an ideal setting for the RAW capture approach; however, I wanted to be sure the be as close as possible to the optimal setting for exposure fusion.

For the whitebalance, the area of the sprocket hole was used as well. The RAW as well as the exposure fused footage was loaded into daVinci. To produce the above example, only lift and gain was adjusted in such a way that visually similar results were obtained.]

The first thing to note in comparing RAW and exposure-fused results is the difference in color. While the RAW results mimics closely the highlight LDR capture, the exposure-fused results drifts into the magenta color. Clearly, the exposure-fused result outperforms the RAW in the shadow areas (see for example the difference in the people’s faces). Note however that no shadow or highlight adjustments are active in the above example. So the full potential of the raw has not yet been unlocked.

Speaking of highlights - comparing the boat’s hull in the left-lower corner of the frame: here the unadjusted RAW outperforms the exposure-fused result! Frankly, I did not expect this outcome. It is reproducable with other capture examples and seems to be connected to high-contrast scenes where the specific exposure-fusion algorithm I am using (it’s not the opencv one) is having difficulties in squashing all the information into an 8-bit per channel image.

Generally, the exposure-fusion algorithm performs quite well and delivers images which are nice to view. Here’s another example:

Note that the color cast visible in the highlight LDR shows up again in the RAW capture. The exposure-fused results looks better, color-wise. But remember - only lift and gain have been used to align the results of both capture ways.

Trying to make both ways more comparable, here’s the result of this effort:

Specifically, the RAW capture has now a shadow and highlight treatment (shadows: 50, highlights -6). Color temperature and tint was also adjusted (Temperature: -390, Tint 22). Saturation was also increased slightly, with setting Sat to 63.

Now RAW and exposure-fused capture become comparable. It seems that the exposure-fused results generally creates per se a slightly more “brilliant” image. This is to be expected from the way exposure fusion works and is a general trend. However, one should be able to handle this with further color grading efforts.

Now turning toward another issue discussed above - severly underexposed images. Here’s the example I selected:

While the highlight LDR shows nearly nothing, the unmodified RAW capture displays already a little bit more image content, the exposure fused result outperforms already the RAW one. This footage is quite difficult to grade, I tried my best and arrived at this result:

Clearly, the RAW result is more noisy, as it would be expected. The noise is mainly present in the red channel - this channel is traditionally more noisy than the other color channels in HQ footage. Here’s the RAW frame developed not in daVinci, but RawTherapee:

Notice the horizontal banding? To make it obvious, here’s the red channel alone:

So Pablo (@PM490) is somewhat correct in his assessment.But Jan (@jankaiser) as well. One has to take into account that we melting down a raw 4K image to an at most a 2K image output image - and if this is done right, one gains a bit of dynamic depth by the size reduction. Also, you probably would keep footage that dim nearly as dim as it already is - most probably you would not increase brightness so much that you turn night into day…

For my own scanner/workflow, I do see advantages in switching to a raw workflow. I will have to write additional software (for example, a sprocket-alignment procedure for raw files) and I need to look (again) more closely into the color science involved (I have the suspicion that the embedded camera metadata of picamera2 is still not 100% correct).

[For people doing their own experiments, maybe using RawTherapee as development tool. At least my program version uses “Capture Sharpening” as default, like here:

RawTherapee default

Make sure to turn this off, like so:

RawTherapee correct

… that’s all for now :sunglasses:]

4 Likes

@cpixip,

A truly interesting comparative study.

For my part, I am in the process of adapting my software to make the captures in jpg (with or without HDR fusion), raw-dng or both at the same time, in this way we can always choose the one that we like or suits us best.

The first results are quite promising. Raw captures, despite the considerable size of the generated files, are made in similar times to jpg captures with HDR fusion.

I’ve run into an unexpected problem. The computer I use for the captures is not suitable for DaVinci Resolve. Within a few minutes it reaches such a high temperature that it locks up and restarts spontaneously.

I have to do some batch testing with RawTherapee to see what happens.

3 Likes

@Manuel_Angel - daVinci is quite demanding. But the days that a program might crash a computer should be over. A new studio version was released just a few days ago - you might try this one out. One common failure mode which still exists with high demand software: trying to run it on a notebook. Notebooks have notoriously featured insufficient venting. Pair that with too much dust in the venting channels and you are asking for trouble. Cleaning might improve the situation, but I would never do editing on a notebook. Get the best desktop machine you can afford, consult the software manufacturer for appropriate specs.

On the other hand - processing raws into 16 bit pngs outside of your editing program might give a speed advantage during editing and color grading. Raws tend to slow down daVinci quite a bit and dedicated raw developing programs might have a few more advanced options for development. Not sure what the optimal workflow will look like.

3 Likes

Picking this conversation up from the other thread, now I’d be curious to see how the RAW version of that underexposed fish example turned out with a handful of identical exposures averaged together (without the fusion algorithm).

That should clean up most of the characteristic rolling shutter banding and get the noise floor down in the vicinity of the fused version.