Would it be better if we say what ITCWB is good for and what problem it is trying to overcome?
My final comments are about the camera-based perspective tool.
The focal length and crop factor (and any additional cropping such as a digital zoom) are combined automatically inferred from the image metadata
This makes it sound like any crop is retrieved from the metadata, but in reality, only the focal length and crop factor are used. The user is responsible for accounting any cropping not already factored into the focal length and crop factor metadata, e.g. by increasing the crop factor and using the horizontal/vertical shift to re-align the image center with the optical center.
We should elaborate on the other aspects of the tool.
- There are three buttons for automatically detecting lines in the image and correcting the perspective in the vertical direction, horizontal direction, or both. Automatic correction works well in most cases where the image has visible horizontal and/or vertical lines.
- In case the automatic option fails to find lines or gets confused by irrelevant lines, the user can opt for the control lines option. The user draws lines over the image. When complete, RawTherapee will use those lines to calculate the correction. As long as there are at least two lines in the same direction as the correction direction, correction will be applied. This means it is possible to control which direction(s) get automatically adjusted by drawing the appropriate number of lines in the corresponding direction.
- After correcting the perspective, users can make some final adjustments to the rotation, shift, and perspective recovery. The recovery option is particularly useful if a perfect correction is not desirable. For example, an image of a building may look strange if the building does not “lean back” slightly. One possible remedy is to reduce the amount of correction. This technique leads to a problem if perspective correction is applied in both directions or if post-correction rotation/shift are used; The lean will be tilted to one side. The solution is to use recovery, which ensures the lean is always centered.
The two images I supplied should have captions. The first demonstrates control lines being drawn to correct the perspective in both directions. The second shows the result of applying the correction with some recovery.
That’s all I have to say for now. Thank you @patdavid for writing this wonderful piece!
I too am in favor of simplifying the presentation of Color-Correlation Automatic White Balance.
I can propose the following text (although I don’t mind the detailed explanation, it is only out of step with the other presentations)
Excuse my bad english:
This algorithm “Temperature correlation” is based on a comparison of Raw data of the image (those majority), and a base of 200 colors representative of the visible colors (and not virtual) in spectral data.
The system proceeds in several iterative steps, using a correlation of data (Student) to :
- search for the best Temperature;
- search for the best green point (tint).
The system gives good or very good results when the illuminant of the scene, during the shooting, is either “Daylight (between 4100K and 12000K)”, or “Blackbody (between 2000K and 4100K)”
First excuse my bad english…
Some new things about Rawpedia and the HDR-SDR and Cam functions in Rawtherapee :
In association with @Wayne_Sutton , we have agreed, to make it clearer, and more educational to :
- remove from “Getting Started” almost everything related to HDR or SDR functions using specific concepts and tools such as “Log encoding”, “Cam16”, “JzCzHz”, Sigmoid"
- these tools are now grouped in paragraph 3 :HDR to SDR : A first Approach (Log Encoding – Cam16 – JzCzHz – Sigmoid)
- Remove the most conceptual parts from this last part and incorporate them into the general module: CIE Color Appearance Model 2002/16 - Cat02/Cat16 - Log Encoding – Jzazbz, especially the whole part concerning Jzazbz :Jzazbz – a new experimental CAM ? (Cam16 & JzCzHz)
- The English version is a bit different from the French one (paragraphs 4, 5 and 6), but the translation should be done this fall (it is a lot of work)
- Rawpedia links :
The whole is clearer (at least from our point of view) and allows a better understanding and an easier reading.
Some explanation on these HDR-SDR type functions, on their implementation in Rawtherapee. Of course, you may or may not take it into account to incorporate it in the loads compared to 5.8 :
« Color Appearance & Lighting (Ciecam02/16) » (main)
- has been enriched with Cam16, much more powerful than Cam02
- possibility to choose a level of complexity " Standard / Advanced »
- some modifications requested by users to make this module more user-friendly
In summary this module which seems complex is located at the end of the process, and allows in particular in " Symmetric " mode to bring a " chromatic adaptation " of high quality when the conditions of shooting and the real illuminant are different.
"HDR to SDR : A first Approach (Log Encoding – Cam16 – JzCzHz - Sigmoid)" (Local Adjustments)
When we look at Darktable, we can see that the software has been entirely rewritten based on 3 principles and tools: Remove the Lab* Mode, Introduce a ‘Filmic’ module (which is a logarithmic encoding of the data), review all the colorimetry in RGB mode, and in a current branch develop a ‘Sigmoid’ module.
I don’t make any judgement, but I can see that these changes have caused a lot of debate and communication. What about Rawtherapee?
What about Rawtherapee?:
Use of the Lab mode: (especially in Local adjustments) :
- Certainly it is true that Lab* passes only 7Ev, but only at the level of the output profile (monitor) whose PCS is in Lab mode and in 8bits. From the various tests that I could make with images with high dynamics at my disposal, when one uses Lab in “float”, the conversion RGB=>Lab, and Lab=>RGB is done without any loss at least on images with a Dynamic Range of 15Ev. Certainly in the long run, if we assume that output profiles can use HDR functions, it may be necessary to use HDR-Lab… But note that today most exchanges are done either on paper (which has a very low Dynamic Range) or on the Web. As for buying a real HDR monitor that passes 4000cd/m2, the prices are around 30000 €.
- It is true that Lab* does not maintain color consistency, especially in red-orange and blue-purple. But in Rawtherapee if in “Local adjustments : Settings” you check the 2 boxes “Avoid Color Shift” and “Munsell correction only”, a series of 200 Lut will correct with a quasi perfection these drifts and will not correct the gamut.
- see in Rawpedia :
The “Log Encoding” module :
- I used the excellent work of Alberto Grigio @agriggio , in ART (with some adaptations), to work in RGB mode. Then to solve the problems of lights and colors (and according to the level of complexity chosen: (Basic, Standard, Advanced), you have at your disposal the tools of Cam16, which allow you to work on the components : J = Lightness and contrast , Q = Brightness and contrast using “Absolute luminance”, and the 3 color components (s : saturation, C : chroma, M : Colorfullness)
The « Cam16 » module :
- it is a very simplified version of the Ciecam & Lighting module present in " main ", therefore much more intuitive, it benefits from the advantages of " Local adjustments " (deltaE, working in " full image ", etc.)
- it has a " Sigmoid Q and Log Encoding Q " module: which of course can use the " Black Ev and White Ev " settings. In both cases, RGB is not used, but the Brighness (Q) which uses “Absolute Luminance” is used as a reference. Of course, depending on the level of complexity (Basic, Standard, Advanced) you have different settings.
- I have equipped it experimentally (by modifying the conversion matrixes) with a slider “HDR PQ (Peak luminance)” which allows a first approach HDR, by allowing to set this function between 100cd/m2 and 10000cd/m2.
The « JzCzHz » module :
- is only accessible in “Advanced” mode
- I encountered many difficulties during the first use (with the original matrix, and PQ set to 10000 cd/m2): lack of saturation, artifacts, etc.
- I tried to work around it with various workarounds: for example the “Remapping” function or the slider to adjust the PQ luminance peak (which specialists or researchers can dispute), but now it works more than correctly.
- JzCzHz (which is a simple transform of Jzazbz), is not a CAM (Zcam we tried does not work) : here again I made some workarounds by giving it some CAM functions for “Scene conditions”: Mean Luminance (Yb%), Absolute Luminance, Surround.
- It has (like Cam16) 2 functions " Log encoding Jz " and “Sigmoid Jz” , there again we do not use the RGB mode, but Jz which takes into account " Absolute luminance "
- the code is not optimized (it is in “double” precision), hence a certain slowness.
Of course, you can help yourself with the documentation in Rawpedia.
Your opinion is important : what do you think ?
So is the release coming or not?
Judging from the stream of posts above your post it seems it’s being prepared.
That was already about 2 weeks ago. I guess @Morgan_Hardwood 's free days are over? And nothing happened?
But I think he he is not responsible for releases.
I can do nothing for release.
I hope, I hope…
I wait since one year…
This has happened several times already. Morgan has popped in to ask for the status of the codebase and planned to make a release, only to suddenly stop communications. I wish we could have more insight into his availability and progress, but life is unpredictable. If he doesn’t come back, maybe we will attempt to figure out the release with the help of Roel when he’s “fully” available again.
I have looked at the work you have done to summarize in an educational way, the work of each contributor.
It is very well done, thank you.
Just a remark
for “LocalAdjustments” the last link
“High dynamic range images - use Log Encoding or the “PDE” algorithms in the “Dynamic Range & Exposure” tool”
It should be replaced by :
“HDR to SDR: A first Approach (Log Encoding - Cam16 - JzCzHz - Sigmoid)” which is in the new paragraph 3. This includes the previous examples and of course all those mentioned in the title
Thank you again
I think that it would be easier to keep track of your progress if you could put this link at the top of the page rather than somewhere in the middle.
Sorry for the radio silence these past few days. We have COVID running in our household at the moment and it knocked me on my ass for a couple of days. I need to catch up on some work things but I’ll come back to address everyone’s comments/additions since my last post!
I don’t use RT, but i do have a small suggestion. I would drop the word “yet” from the title. To me it implies that it will happen. I don’t think that’s the message the team wants to convey.
Just what I thought.
It’s a Monty Python reference (Monty Python and the Holy Grail)
A character says “I’m not dead yet!” with his next line being “I’m getting better!”
The allusion to the movie implies that unless some additional, deliberate action is taken to kill it, the project will get better.
Am I missing something? I see the link to the draft in the first post and the working title is “RawTherapee 5.9 (WIP) and Project Updates”.
They are discussing the URL itself right now
Ok, progress. I’ve had a little bit of time to catch up on the suggestions from everyone so far. (Thank you!).
I’ve included them all
… with the exception of the HDR-SDR and Cam functions… post above from @jdc - as the material is dense and I’m not quite sure where/how to write it in to this post. This feels like it might be a good follow-up post in the coming weeks on it’s own? Especially where we can expand the descriptions and include some fancy graphics perhaps.
On that note, are we looking good for a publication?
If there’s nothing more to add I can look at publishing over the weekend or even on Monday and then pushing to social channels and other outlets to pick up and spread the great news.