Closed thanneken closed 5 years ago
The quality written to the batch file (jpegQualityWebRTI ) is always 100, it is never given a chance to change in the macro so I implemented the same behavior in the plugin. The jpeg quality in the prefs file is only used to run("Input/Output...","jpeg="+jpegQuality)
and is not implemented in the command line commands in any way. That means jpegQuailty in most cases is not equal to jpegQualityWebRTI which is why you see a difference in the preference versus what is written to the batch file. They are different variables and tracked separately.
I was able to fix the casing issue for webGLRtiMaker
I don't think staying with 100 as default is a good idea. There is no subsequent processing and humans would have a hard time telling the difference such as to justify the bandwidth. One option is to use the same value assigned for writings the 56 jpegs. Another option is to keep the default hardwired but change it to 90.
I will refresh myself on this during the sprint.
Users have never been able to set the quality of JPEGs of WebRTI, they won't be missing anything if we hardwire to 90. It is more intrusive to the software to allow that setting a secret side effect of controlling quality in the WebRTI creation process. We will hard wire to 90.
There are two settings that are right in the prefs file but end up wrong in the deferredbatch.bash file.
The first is that my prefs file says jpeg quality should be 90, but the value written to the batch is 100. This may be confusing because there are two phases in which jpegs are written. The least complicated thing to do is to use the same value consistently.
The second is that my prefs file as proper case for
webGLRtiMaker
but the batch file is capitalizing theTI
. This may be related to the other issue of case not being precise, but it may be an additional problem that the prefs file isn't being used when it should (besides case, it could also make a difference if the executable was not in path or the user wanted to specify which one to use).