In the rc2 thread, I have reported (Windows only) problems with non-ascii characters in the Exif.UserComment tag. It was fixed soon, still in rc2, but I have never confirmed this (being occupied and such). To redeem myself, I have now tested it again (rc3), also with the Russian Cyrillic, that I can read only very slowly, and it seems to be still fixed, working well. Sorry for the delay. Thank you!
1 Like
Where get I get info about new features in this version?
Upon opening I get this screen, which I believe is prompting for each image because it kept prompting even when I hit ok.
@Morgan_Hardwood
W10 flto
Build parameters
Version: 5.3-681-g2e9dc1144
Branch: dev
Commit: 2e9dc1144
Commit date: 2018-03-12
Compiler: gcc 7.3.0
Processor: generic x86
System: Windows
Bit depth: 64 bits
Gtkmm: V3.22.0
Lensfun: V0.3.2.0
Build type: release
Build flags: -m64 -mwin32 -mthreads -Wno-aggressive-loop-optimizations -std=c++11 -mtune=generic -Werror=unused-label -flto -fopenmp -Werror=unknown-pragmas -Wall -Wno-unused-result -Wno-deprecated-declarations -DNDEBUG -O3
Link flags: -m64 -mthreads -static-libgcc -mtune=generic -flto -s -O3 -fno-use-linker-plugin
OpenMP support: ON
MMAP support: ON
part of Build log
[ 4%] Linking CXX static library librtexif.a
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/rtexif.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/stdattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/nikonattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/canonattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/pentaxattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/fujiattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/sonyminoltaattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/olympusattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/kodakattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ar.exe: CMakeFiles/rtexif.dir/panasonicattribs.cc.obj: plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(rtexif.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(stdattribs.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(nikonattribs.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(canonattribs.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(pentaxattribs.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(fujiattribs.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(sonyminoltaattribs.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(olympusattribs.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(kodakattribs.cc.obj): plugin needed to handle lto object
C:/msys64/mingw64/bin/ranlib.exe: librtexif.a(panasonicattribs.cc.obj): plugin needed to handle lto object
[ 4%] Built target rtexif
The plugins seem correctly located by cmake:
CMakeCache.txt (64.8 KB)
Yes now Metadata works normally in compressed tiff!
2 Likes
When is this round closing? I wonât be able to test until the weekend. Thanks!
Black and White conversion produces unexpected results sometimes. It is less intuitive and less usable compared with 5.3 imho.
Devs and anyone, what, if anything, has changed please? Thereâs no mention of B&W conversion in the release notes in âAboutâ.
Hi,
did you file a bug report on github already? If not, can you please do that? Thanks!
In January there was this update to black-and-white:
I compare B/W conversion with the official 5.3 version.
I am not sure that it is a bug, but sometimes if I use âchannel mixerâ tool in B/W conversion tab, image does not change at all while I move RGB sliders and then changes abruptly.
Maybe algorithm of B/W was changed since 5.3 and I need to read documentation again.
By testing RT 5.4 rc3 I scrolled through older jpg-files in a couple of directories and had a close look in a few of them (RT file manager - open a file, file manager - change directory - open a file âŠ). After a few minutes RT got frozen. This result was repeatable.
Attemps to get a debug-file were not successful because gdb also seemed to be frozen (no further command could be entered after RT got frozen). By working with raw-files I couldnât find any problem.
By the way: many thanks to all actives for doing a really great job!
Greetings Heinrich
I am not aware of any intentional change. If you can, please file a bug report with an example of the differences between the behaviour of 5.3 and the current one. Thanks!
There is a sudden jump with channel mixer when the 3 sliders (not the gamma ones) add up to zero and then you go to -1. I think it has done this for quite a while. I once thought it a bug but now regard it as a feature! and Rawpedia refers to getting creative IIRC. I like channel mixer.
The January change says speedup (and involves going 32bit??) so presumably not a functional change.
I checked the change: Itâs fine. I also tried to reproduce the problem based on the sparse information we have, but could not reproduce.
Which OS? Howâs the CPU load when âfrozenâ?
@ Flösie: OS is win64 and CPU load was low, about 1 to 2 %.