on Windows 10. When
is selected in
, not all of the auto check boxes under it appear to work.
@afr-e
Effectively, the "auto check box" - "Temperature viewing conditions" was forgoten .
I just push a change
Thank you very much
Jacques
Another bug: changing values using number boxes don't commit unless I choose another object. Pressing enter doesn't change the preview either.
@afr-e
This second bug is an internal GUI problem, which I don't know how to deal with at all :)
jacques
@afr-e The first part of your remark is something that is not unique to the CIECAM tool: manually typed values only commit after pressing enter or changing focus. I think that's expected behavior (but you might disagree on the usefulness).
The second part is strange and seems specific to CIECAM. @Desmis Jacques, I think you might not trigger the preview update properly somehow... Maybe @Floessie and @heckflosse already have a solution for that in the new autoupdate2 branch?
All is possible...but this behavior must not have changed since 2012...because all this part of the code is unchanged...
But if someone shows me what to do, then why not
manually typed values only commit after pressing enter or changing focus. I think that's expected behavior (but you might disagree on the usefulness).
I am unable to open RT ATM but something is different with the behaviour compared to other places. Maybe it is that in some other places manually typing does change the preview without committing...
afaik there is no adjuster in RT where manually typing values does trigger a preview update without hitting enter or switching to another adjuster (using the tab-key)
I just wanted to confirm what @afr-e described.
Most of the adjustments in the CIECAM module do not update the display after entering numbers and then pressing the tab or enter key. However, they will subsequently update the display if the '+' or '-' buttons are clicked, if the mouse is clicked on the same or a different number box, or if the module is turned off and back on. I'm using the Ready/Processing Image progress bar as the display update indicator.
Some of the controls do work as expected, though; for example, under Viewing Conditions: Tint, and Mean Luminance.
Also, the Viewing Conditions/Temperature defaults to 5000, but when the Reset arrow or the auto check box are clicked, the number changes to 5003. The tooltip window indicates that 5003 corresponds to D50, so 5000 appears to be an error of some sort.
I'm currently using RawTherapee_dev_5.8-2697-gd2cd5f2_20201228.AppImage.
(The CIECAM module is not very well documented from a user perspective, which doesn't help matters any.)
@afr-e @reffort
Thank you for testing and reporting...
I think, the problem is probably due to the fact that originally the code was in double precision and not yet optimized (SSE, OMP...) by Ingo @heckflosse
As a result, functions were implemented to "reduce" the speed of the GUI, as the code required a lot of processing time
I change also some default values (5000 ==> 5003)
commit 66908b6c5 in "dev"
For the documentation , I made a development of Ciecam at the end of November 2020 .
Maybe that's not enough....???
https://discuss.pixls.us/t/ciecam-and-rawtherapee/21368
jacques
I will be away for a few days, starting tomorrow morning.
Jacques
(These comments are based on RawTherapee_dev_5.8-2709-g66908b6_20210106.AppImage.)
The display update issue appears to be resolved.
The Viewing Conditions/Temperature Auto check box does not seem to do anything unless the module is in Symmetric mode. In normal mode, I can move the Temperature slider to some arbitrary temperature, then check the Auto box, and the temperature does not change--it remains at the arbitrary temperature.
There are still a couple of nuisance-level things with some of the numbers: Scene Conditions/Absolute luminance, and Viewing Conditions/Temperature. After loading the Neutral Processing Profile, then clicking the Reset arrow with a Click and then a Ctrl+Click, I see:
Control | Initial | Click | Ctrl+Click
--- | --- | --- | ----
Scene/Absolute luminance: | 2000.00 | 2000.64 | 2002.99
Viewing/Temperature | 5003 | 5003 | 5000
The tooltip indicates that a Click resets to the "default" value, and Ctrl+Click resets to the "initial" value. I'm not sure what the distinction is between them, but I don't feel too bad about it because the mouse click doesn't seem to know, either(!). Scrolling the mouse wheel on the slider results in different change values up and down for the Scene Luminance, and the amount of change is much too small to be of any use. Temperature moves by 6 Kelvins, where 5 might be more intuitive. I didn't formally check any of the other sliders, but I think someone needs to review the module and make sure everything is actually working as intended.
There might be some terminology issues at play, too. For example, "Absolute luminance" appears to be called "Adaptive luminance" in the Fairchild text.
Regarding that pixls.us page:
I agree with the review author on both counts. There isn't anything I know of that describes in plain language what the CIECAM module does or what the controls actually do. The auto mode often does pretty well without any intervention, but often it results in images that are somewhat garish (too magenta, too bright, oversaturated colors). So, what I would like to see is information that would allow me to operate the controls intelligently, instead of using the "play with some sliders until you see something you like" approach.
There being no alternative I did just that, and played with the sliders much longer than seemed reasonable (a couple of months). What I found is that the settings I like best are usually the defaults (click the Reset arrows), with occasional adjustment of Yb. Based on the description in the Fairchild text, the default settings are pretty much what CIECAM02 was designed around. Additionally, several of the controls in the Scene Conditions and Viewing Conditions have to be changed a great deal to have much visual effect; knowing that up front would have saved a lot of "play" time.
Of the five "What's it for?" examples referenced on the pixls.us page, the only one I've used is the first one: adjusting Yb to lighten a dark scene or to darken a light one. The other examples would be, for me, special cases.
The Rawpedia article could, I think, be organized more along the lines of: first, what a user might want to know (what does it do? what happens when _____); then the supporting and background information. (Rawpedia seems to be, in general, more bit-nerdy than it needs to be.)
I have been busy this past year, so my reports have been vague at best and I haven't been following up. So @reffort, I am glad you are asking questions. @Desmis's mother tongue is French. @reffort If you see anything worth clarifying, please help if you can.
I've printed out the CIECAM section of the manual and will look through it. I was already planning to see if I could make any improvements to it, and have been putting it in a format that is easy for me to edit. Some of the problems I had were due to a section that describes what appears to be an old implementation--the UI has changed significantly since then. The author even says in one place that lack of documentation about CIECAM is a problem, so it would seem that I am not alone in that opinion! The English is not a problem; it's really pretty good for the most part.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, January 8, 2021 3:20 AM, afr-e notifications@github.com wrote:
I have been busy this past year, so my reports have been vague at best and I haven't been following up. So @reffort, I am glad you are asking questions. @Desmis's mother tongue is French. @reffort If you see anything worth clarifying, please help if you can.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
@reffort @afr-e
I am attentive to your requests
For the term "absolute luminance", a few years ago the wording was "adaptation" (in internal the 2 variables are 'adapscen' and 'adaplum') , but I was asked to put "absolute" because some authors use this term (I believe J.Hunt).
Note that part of the automatic calculations come from personal reflections (not for Chromatique adaptation)
When you mention the old documentation and its author...that's me. It was simply translated from French by an English speaker.
When I speak of "lack of documentation" it is not at the RT level, but at the level of universities or software or users...I am not J.Hunt, I am not Fairchild...
When you look at the softwares that use Ciecam completely...they are very very very rare, until recently there was only a plugin for Photoshop, not or little documented.
Since october 2020, you have now "Little CMS color abstractor"....
The recent documentation was done with the collaboration of an English-speaking person Wayne Sutton. In addition to the language we exchanged on pedagogy...Of course we can improve it.
But it is not simple.
The subject is complex because of the nature of the vocabulary and the cognitive shortcuts that users realize (I'm not talking about you). They are so accustomed to Lightroom, DxO...and tones-curve.
The knowledge in colorimetry is in general weak, then in the case of Ciecam one "adds" the phisiological side.
But I am open to any improvement within the limits of my skills.
jacques
The Rawpedia article could, I think, be organized more along the lines of: first, what a user might want to know (what does it do? what happens when _____); then the supporting and background information. (Rawpedia seems to be, in general, more bit-nerdy than it needs to be.)
I agree entirely. I haven't got the time or the expertise to do anything other than the translations I did for the worked examples so anything you can add would be great.
I had not seen the November version of RawPedia until the past few days. It does address some of the issues I mentioned. My apologies for not checking that. I had not downloaded an updated copy of the PDF because it is a rather large (31MB) document.
I think most of the UI items I referenced are related to having consistency from a user's viewpoint. They seem to be minor things that have escaped notice because they are so minor.
On the Viewing Conditions > Temperature > Auto check box, I was thinking that in Normal mode that "auto" could perhaps set the temperature to 5003 (or whatever the default is) rather than try to calculate something. Another thought is that maybe it could just be grayed out if it isn't supposed to do anything and there's no practical alternative. But mainly, I think that it probably should "do something" when it is checked, otherwise it has the appearance of a bug (regardless of whether it is or not) because it does "do something" when it is checked in Symmetric mode.
Yes, when I referred to author commenting on the lack of documentation about CIECAM, I did mean at the general level (academics), not the RT document. It occurred to me that if someone who understands the details well enough to code it (that's you) thought that it wasn't adequately documented in the literature, then maybe even the folks who invented it might not know how it works!
When I get the CIECAM document copied into a structured format and study it a bit, I'll upload a copy for review and feedback (I have no expertise in the CIECAM area; I'm just trying to understand how it works so I can make the best use of it). Is there a location that would be good for that? It doesn't seem like an Issue would be the best place to work on a document.
Sent with ProtonMail Secure Email.
@reffort @waynesutton50
Hello
I don't know, who and when are done the PDF documents...but it seems "old"....The good way are the "rawpedia" (in french...or in english)
In the last commit, I have suppressed the "auto checkbox" for "Viewing conditions" ==> Temperature
I think if you accept, as a first step, to work at 3 in Private Message (PM). Then when we will be satisfied with the work of sharing and enriching by an issue or a topic in Pixls.us
Thank you
Jacques
@Desmis
I don't know, who and when are done the PDF documents...but it seems "old"....The good way are the "rawpedia" (in french...or in english)
Could you clarify this a bit please? The PDF documents are auto-generated by a script, following the rules of a special RawPedia page.
What do you mean when you say the PDFs seem _old_?
What do you mean when you say that the _good way are the "rawpedia"_?
I am the one behind the way those PDFs look, and they are not so different than the online version, IMHO. I agree that it was a long time ago when I updated the layout, but it won't ever look as good as the online version, as the conversion from HTML/CSS to PDF is «delicate» at best (if not simply impossible).
If you point to the styles or ways to present data in the printed (PDF) pages that need an update, I'll try to make it happen (but no promise).
EDIT:
OH! And don't forget that you must follow the guidelines written in the «Coding RawPedia pages» page, or you won't take full advantage of the styles created, nor the layout intended when coding it (including PDFs).
Hello Xavier
Thank you for your advices.
I never used these Pdf...and sorry for my bad comments
When i say prefering Rawpedia, it is for the links... but perhaps they
works also in pdf ?
Thank you again, and sorry again
Jacques
Le jeu. 14 janv. 2021 19:42, TechXavAL notifications@github.com a écrit :
@Desmis https://github.com/Desmis
I don't know, who and when are done the PDF documents...but it seems
"old"....The good way are the "rawpedia" (in french...or in english)Could you clarify this a bit please? The PDF documents are auto-generated
by a script, following the rules of a special RawPedia page.What do you mean when you say the PDFs seem old?
What do you mean when you say that the good way are the "rawpedia"?
I am the one behind the way those PDFs look, and they are not so different
than the online version, IMHO. I agree that it was a long time ago when I
updated the layout, but it won't ever look as good as the online version,
as the conversion from HTML/CSS to PDF is «delicate» at best (if not simply
impossible).If you point to the styles or ways to present data in the printed (PDF)
pages that need an update, I'll try to make it happen (but no promise).—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Beep6581/RawTherapee/issues/6022#issuecomment-760393385,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADJAQWJ7CIZ7QPIQIGOBFBDSZ43JNANCNFSM4UY6NJ3A
.
Jacques, the comments where not good, nor bad. I just didn't understood them. And I don't use the pdf, either.
About the links: they work in the pdfs, but the word/words that are the link indeed are not highlighted (with a distinct color or underlining). If you point to the words just before the written link (in blue), you will see that the pointer changes to a hand (a link).
I can change the color of those words if it's better that way. And I can remove the written link, but it is my understanding that in a printed page they are needed. Take into account that the pdfs look exactly the same as the real paper printed page, as they are generated the same. And in a paper there is no mouse...
In advance of any comment, those images alone in pages (half page blank), or the images cut in half are a bit of a nightmare and I haven't found a way to properly laying them out (aside from making them much smaller). So any hint about this will be welcomed.
And any other improvement in the pdfs would also be welcomed, just point out where there's an improvement to be made. Here, or in PMs if you feel this is out of topic here.