RawTherapee
RawTherapee copied to clipboard
Beep6581
Support DNG WarpRectilinear opcode
Originally reported on Google Code with ID 2858
Hi,
I'm using RT for quite some time and I really like it. I'd like to post a feature request.
The idea is to support the WarpRectilinear opcode that some DNG files have. The opcode
specifies how the lens distortion should be corrected when demosaicing the DNG file.
Code for reading the opcode and correcting the distortion is available from Adobe as
part of the open source DNG SDK, in the utility dng_validate. Currently RT ignores
the opcode and therefore DNG files that contain it are uncorrected for distortion.
The ZIP file linked below includes the following files:
1_P7183225.ORF - Original RAW file in ORF format (taken with an Olympus E-M10 camera)
2_P7183225_OOC.jpg - Out of camera jpeg (downsized to 1MP)
3_P7183225.dng - DNG 1.4 file created with Adobe DNG Converter
4_P7183225_RT.jpg - Output of DNG file when converted to JPG in RT
5_P7183225_DNG_VALIDATE.tif - Output of DNG file when converted to TIFF using dng_validate.
ZIP (35MB):
https://dl.dropboxusercontent.com/u/21642925/RT_DNG_OPCODE.ZIP
As you can see, the out of camera jpeg and the file created by dng_validate are both
corrected for distortion, while the file created by RT is not.
I tried to work with the DNG SDK in the past but it's a nightmare to get it to compile.
I didn't manage to build dng_validate locally. I'm also not familiar enough with RT's
code to implement such a feature by myself currently. I hope that this can be implemented
sometime in the future.
Thank you,
Assaf
Reported by assaft on 2015-07-26 20:03:33
While I have nothing against flexibility and supporting yet another automated distortion
correction method, I wanted to point out that the Auto Distortion Correction button
correctly fixes the distortion in your ORF with a single click, see:
http://filebin.net/6walygxqyu
Furthermore, Ingo is working on lensfun support in issue 2543, making this DNG-only
method seem less appealing.
Reported by entertheyoni on 2015-07-27 19:08:20
- Labels added: Type-Enhancement, Component-Tool
- Labels removed: Priority-Low
Thank you for the information.
I didn't notice that the automatic distortion correction worked flawlessly for this
file. This is great but I also noticed some inconsistency in its operation, as other
shots at the same focal length were corrected differently. Sometimes it fails to correct
properly.
I'm aware of Ingo's work and I consider it of a great value. I'm looking forward to
the integration with LensFun as it will simplify my workflow and make the distortion
correction more consistent. However, there are two limitations with the LensFun approach:
1. Availability - LensFun is not complete and will ever be because new lenses are coming
out all the time. It seems like all mirror-less systems use the same trick of distortion
correction by software so we are likely to see more and more lenses that require such
correction. The DNG approach that I suggested covers all present and future lenses,
because the conversion from a propriety RAW file to DNG is easy using the free Adove
DNG converter, and this way the distortion correction info coming from the lens (even
a lens that was released just a day ago) is translated into the open DNG format. Then
the DNG can be opened in RT and (if the feature is implemented) then the distortion
will be corrected based on the WarpRectilinear opcode.
2. Quality - LensFun profiles are made by users while the lens correction info stored
in the RAW file was prepared by the lens manufacturer. In a way, the DNG approach,
which relies on the RAW file, shows how the correction should be done 'by the book'.
They are not perfect either (PTLens have some interesting examples), but it's useful
to have them as a reference and for cases were LensFun profile seems off.
In short, the DNG correction approach is future-proof and equivalent to the out-of-camera
distortion correction. It is supposed to be a viable solution for all cases in which
a lens is missing from LensFun or handled incorrectly.
Reported by assaft on 2015-07-28 00:07:13
It seems to me that those limitations apply to DNG too: availability is not universal,
all present lenses are not covered, only some DNGs have those opcodes, and there is
no reason to believe Adobe's parameters are any better than those prepared by meticulous
users. Just look at the amount of bad control points in Adobe LCP files or at what
they do with their color profiles.
"In short, the DNG correction approach is (...) equivalent to the out-of-camera distortion
correction" That's how the Auto Distortion Correction feature works - it relies on
the embedded JPEG image being corrected and then calculates parameters to replicate
that in the raw file.
Again, I'm not shooting down the opcode idea, I just feel you're a little over-enthusiastic
and drawing wrong conclusions.
Reference:
The Adobe DNG Specification 1.4.0.0 from 2012, page 83 onwards.
http://wwwimages.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf
Reported by entertheyoni on 2015-07-28 09:18:46
Thanks again for the info and for raising these points.
I want to clarify some things about the workflow that manufacturers like Olympus and
Panasonic (and I assume most if not all other manufacturers that rely on software correction)
envisioned and support:
When taking a picture, the camera reads a 'lens profile' from the hardware of the lens
and stores it in the RAW file. The RAW files are proprietary and it is unknown to the
open source community how to decode the lens profile. The manufacturers share this
information about the lens profile only under certain agreements with specific RAW
developers like Adobe's. It is required from such RAW converters that they won't expose
the image to the user in its uncorrected stage. This guarantees that the correction
is automatic.
Flow 1 - direct conversion to bitmap:
When the RAW file is developed, the RAW converter is supposed to apply the correction
based on the lens profile. This can be done in-camera of course when shooting JPEG.
An external RAW converters can do that only if it knows how to read the lens profile.
The OEM converters do that, and those that have the said agreement with the manufacturers.
Flow 2 - intermediate conversion to DNG (before conversion to bitmap):
Using a tool like LR or Adobe DNG Converter, it is possible to switch to the DNG container.
In this process the lens profile is read from the original RAW file and transformed
into the DNG WarpRectilinear opcode. In practice this decodes the propriety lens profile
and makes it readable to any RAW converter (because the DNG standard is open - thanks
for linking to the spec PDF). Note that the transformation of the lens profile into
the opcode is software based; it's not like a profile that Adobe needed to prepare
specifically for this lens or another. It's an algorithm that was already provided
by the manufacturers to Adobe years ago and it is used for all present and future lenses.
As a result, when converting the DNG to bitmap, the correction is supposed to be equal
to the correction applied by Flow 1.
I hope that this answers most of the points you raised. Just to make sure:
1. The availability is universal and future-proof: any new lens comes equipped with
a lens profile, which is saved to the RAW file when shooting, then transformed to the
DNG (if Flow 2 is employed), and at the end can be read from the opcode based on the
open standard.
2. The correction based on the opcode is exactly the same correction as done in-camera
or by OEM RAW converters. So quality-wise it is supposed to be good. I'm not saying
anything negative about profiles prepared by meticulous users. I'm just saying that
this guarantees that the correction is 'by-the-book' as envisioned by the manufacturers.
3. The correction data is provided by the manufacturers, not by Adobe, and there's
no need for any effort from Adobe in maintaining Flow 2. Adobe only converts the representation
of the lens profile from the propriety RAW file to its DNG format. This is done based
on specs and possibly code provided by the manufacturers.
Reported by assaft on 2015-07-28 10:33:02
no, but I can take a look at this when time permits. I consider the lensfun integration higher priority though
Small thing to add: you may notice, that file from DJI is not perfectly straight. There is LCP profile (https://phantompilots.com/threads/adobe-lens-profile-for-p4p-posted.98518/page-2#post-1165977) that additionally corrects distortion AND vignetting. I think, that opcodes (when available) should not disable LCP correction.
It seems to me that those limitations apply to DNG too: availability is not universal, all present lenses are not covered, only some DNGs have those opcodes, and there is no reason to believe Adobe's parameters are any better than those prepared by meticulous users. Just look at the amount of bad control points in Adobe LCP files or at what they do with their color profiles. "In short, the DNG correction approach is (...) equivalent to the out-of-camera distortion correction" That's how the Auto Distortion Correction feature works - it relies on the embedded JPEG image being corrected and then calculates parameters to replicate that in the raw file. Again, I'm not shooting down the opcode idea, I just feel you're a little over-enthusiastic and drawing wrong conclusions. Reference: The Adobe DNG Specification 1.4.0.0 from 2012, page 83 onwards. http://wwwimages.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdfReported by
entertheyonion 2015-07-28 09:18:46
Just to reiterate what assaft said, as I believe it is important to understand why we really need to be able to use the opcodes: it is my understanding that these opcodes are included in the RAW file from within the camera itself. That is, it is not added by Adobe based on some algorithm which compares the JPEG to the RAW data. Adobe translates the (possibly proprietary) 'opcodes' into the DNG opcodes.
no, but I can take a look at this when time permits. I consider the lensfun integration higher priority though
Since the opcodes can perfectly correct distortions and vignetting etc., what is the advantage of lens profiles offered by e.g. Lensfun over employing the DNG opcodes?
Although Lensfun is now supported, I am not sure what other information is in a lens profile (LCP file) that warrants making one, using software like Lensfun and Adobe Lens Profile Creator. That is, I would like to know how is a lens profile useful on top of the built-in information in the raw file, such as the proprietary information/opcodes?
I've been reading up on pages like http://rawpedia.rawtherapee.com/How_to_create_LCP_profiles and https://rawpedia.rawtherapee.com/Lens/Geometry but any clarification to this matter is appreciated.
I think that we really need the opcode support to support new cameras immediately. Actually, we might want to even support the proprietary lens correction parameters from the raw files. This would be somewhat difficult as it would require some reverse engineering--as you say the files from the manufacturers are proprietary and only shared with parties like Adobe--but shouldn't it be possible?
Here is a picture of a straight road. It's a CR3 raw file from the Canon G5 X Mark II, for which lens support is currently absent in RawTherapee. Automatic distortion correction does not work flawlessly. I challenge you to perfectly correct the geometric distortions and visible blurry lens hood, without making use of a lens profile (which does not yet exist for the G5 X Mk II anyway). JPEG included for validation directly below.
@Streep How is this an argument for the (difficult) implementation of opcode handling? A lensfun profile should handle your challenge quite easily, and the database is still updated regularly for new lenses as far as I know.
For what it's worth in your example, the DNG is cropped quite strongly with respect to the original CR3. That makes getting rid of the vignetting much easier. I can already get quite close with the default tools in RT. Granted, your OOC JPEG looks better, but getting something decent is already possible.
Also, in Adobe products, e.g. Lightroom, of course the built-in lens corrections are applied, but can not be deactivated either. I'm not sure of the reason for this, but in any case, as you say:
It is required from such RAW converters that they won't expose the image to the user in its uncorrected stage.
On the other hand, you are able to select a lens profile from another camera. However, the "Built-in lens profile applied" is still showing and the effects on the image is rather minimal.
To be clear what settings I'm talking about, here is the relevant screen snippet (after setting some bogus settings that don't make sense):
Also, chromatic aberration can be selected separately, for some reason. And the Distortion can also be set by a slider, whatever that does (how can you even have a 'strength' for applying a lens profile?).
@Streep How is this an argument for the (difficult) implementation of opcode handling? A lensfun profile should handle your challenge quite easily, and the database is still updated regularly for new lenses as far as I know.
For what it's worth in your example, the DNG is cropped quite strongly with respect to the original CR3. That makes getting rid of the vignetting much easier. I can already get quite close with the default tools in RT. Granted, your OOC JPEG looks better, but getting something decent is already possible.
I get your meaning. It's just that if you are quite new to all this stuff then it's nice to have something working out of the box, something which Adobe products offer, even for new cameras. In addition to that, it's nice when you know that the original manufacturer's lens data has been applied.
I already surmised there is an explicit crop done here. So I guess there are also opcodes for crop? Again, I'm not sure what information is in a full lens profile compared to data built-in by the camera (as per my previous beginner questions ;-) ).
Besides that, it's kind of mandatory that things work fast. That's of course offered by a lens profile. But in the absense of one, I can only make manual corrections like you did, which is for me not feasible when I have lots of pictures. To conclude, I cannot really use RT with this camera now.
@Streep I think that lensfun can do a satisfying job at correcting distortion and vignetting. What is missing in compact-canon.xml file is the reference to your camera. So adding in this file
<camera>
<maker>Canon</maker>
<model>Canon PowerShot G5 X Mark II</model>
<model lang="en">PowerShot G5 X (3:2)</model>
<mount>canonG7X</mount>
<cropfactor>2.72</cropfactor>
</camera>
solves the problem. If you want a definitive correction, file a ticket in the lensfun site.
(no crop done)
I've noticed that perspective corrections are done before distortion. Should I create another ticket for this?
Since the opcodes can perfectly correct distortions and vignetting etc.,
I think that this is incorrect, or at least depends on the mount specifications. Two points:
- In the case of micro-four-thirds, the embedded profile corrects distortion only and does not deal with vignetting. At least with the few cameras that I have, Panasonic and Olympus,implemented the menu option of vignetting correction by applying the correction to the RAW data directly - a very strange decision if you ask me. Ricoh did a similar thing with the GR. Other manufacturers might differ.
- The correction of distortion is not necessarily perfect. Sometimes the lens manufacturer prefers to leave some amount of distortion uncorrected because a perfect correction would require too much cropping that yields smaller field-of-view than specified for the lens. In the end, it is a manufacturer decision how to balance between optical correction and software correction, and to what extent to leave some distortion in order to stay within the formal specifications.
what is the advantage of lens profiles offered by e.g. Lensfun over employing the DNG opcodes?
I'm the OP of this thread, which is almost 5 years old, and I think that we are in full agreement about the benefits of supporting the DNG opcodes. As I already tried to explain, there are two main reasons for this:
- DNG opcodes specify the correction as designed by the manufacturer. This should satisfy almost all users, and provides a reference for a fine correction.
- DNG opcodes are available for any lens from day one in the market. Even for a lens that has just been released, the free Adobe converter can be used to convert the RAW file to DNG and this converts the proprietary lens profile to the DNG opcodes.
As I mentioned earlier in this thread, the source code for applying the opcodes distortion correction is included in the free source code of the DNG validation tool from Adobe.
Regretfully, there seems one thing is missing: the dev willing and having time to integrate this function in RT :disappointed: Perhaps you could volunteer?:smiley:
Hello all, I have implemented the WarpRectilinear function in the DngOpcodesEditor that I released few days ago. Maybe you can play with it and see how it's implemented. It supports a single plane now, but can be easily extended. Cheers, Leonardo
