https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #20 from Guenther M. Erhard <[hidden email]> --- There is feedback from libraw project: "In Libraw 0.17 and newer we added additional data type check. Original (from camera) images passes it, while digikam-imported are not. After digikam procesing (on import), type field for metadata tag 0x2020 is altered and set to 4 instead of original value (13)." It seems that this has an influence on the cooperation between dk and libraw. I work currently with dk 4.13 compiled to use libraw 0.16 (my systemwide lib). Is there a way to compile dk5.x from git or tarball with the systems libraw? I have tried to replace the libraw 0.18 src in core/libs/rawengine with my 0.16 src, but it did not work well. -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #21 from [hidden email] --- If i understand the thread in libraw forum, the Thumbnail Thread interface in digiKam do not take the largest preview to render the thumb in icon view. Typically, ORF is based on TIFF/EP, and the first thumbnail returned in a small one from Exif thumbnail tags. We need to check this image size to see if it enough largest accordingly with thumbnail max size set in config dialog (typically 256 or 512). If the condition is false, we must take the preview JPEG embeddedin RAW files. The code relevant is in this file : https://quickgit.kde.org/?p=digikam.git&a=blob&f=libs%2Fthreadimageio%2Fthumbnailcreator.cpp The main wrapper is in ThumbnailCreator::createThumbnail(), which will call ThumbnailCreator::loadImagePreview(). This method will use Exiv2 API to get preview. I think the problem is here with ORF because it take Exif thumb, not preview. We must check if image size taken with Exiv2 is enough large, if not QImage returned must be null. Later in ThumbnailCreator::createThumbnail(), we will try with libraw through DRawDecoder::loadEmbeddedPreview(). This must do the stuff properly. Gilles -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #22 from Maik Qualmann <[hidden email]> --- I can reproduce it. If the option "If possible write metadata to RAW files (experimental)" is enabled Makernotes be changed and the preview image is unsharp after reload (F5). A simple change (rating) is sufficient. Maik -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #23 from Maik Qualmann <[hidden email]> --- No problem with CR2, RW2 or NEF files. Guenther, the option "If possible write Metadata to RAW files (experimental)" is not good for ORF files! I see the problem now in libexiv2. Maik -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #24 from Maik Qualmann <[hidden email]> --- Git commit 7be20c293714a0f325f956e49ec58c54f3161dfc by Maik Qualmann. Committed on 28/09/2016 at 18:07. Pushed by mqualmann into branch 'master'. only perform automatic rotation of JPEG images in the import tool M +1 -1 utilities/importui/main/importui.cpp http://commits.kde.org/digikam/7be20c293714a0f325f956e49ec58c54f3161dfc -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #25 from Guenther M. Erhard <[hidden email]> --- Hello Maik, Is there any progress here? I've compiled a current version from git, but the problem is still there. You mention libexiv2 is probably the root cause when writing to raw files. Is there anything I can check? Thanks Guenther -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #26 from Maik Qualmann <[hidden email]> --- Have you the option "If possible write Metadata to RAW files (experimental)" enabled? When yes, please disable. Import new images from the camera. Thumbnail now ok? Maik -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #27 from Guenther M. Erhard <[hidden email]> --- Yes, the thumbnail after import from camera is now o.k. - regardless of the option setting. The problem starts when meta data is written to the raw, e.g. adding a tag or correcting time. I've done some tests: - change of time in dk53 with the batch tool on a virgin raw file (with thumbnail o.k.) - after change of time thumbnail get blurry - change of time with exiftool on this file (exiftool -createdate+=00:00:01 FILENAME.ORF) - exiftool throws out a warning: "Invalid time string (2016:10:06T15:14:12) when shifting CreateDate - GME15826_1.ORF" and rewrites the file with the new time - after that thumbnail is o.k. again - doing the time change with exiftool on a virgin raw file gives no warning and the thumbnail is still o.k. Now I tried it with exiv2: exiv2 -v -Q d -a 01:01:00 ad FILENAME.ORF: - changing time on a virgin raw file leaves the thumbnail o.k. - changing time on the dk53 time modified file throws no warning and the thumbnail is still blurry So I guess you are right there is something with libexiv2 as exiftool works correctly. My conclusions: - Exiv2 seems not so picky about errors in metadata and copies/writes them again on file changes - If the file metadata is correct exiv2 does not break the file structure when writing - DK works correct when metadata structure is not broken - Writing metadata with DK (using libexiv2 I assume) into orf raw breaks the structure So I think there is either something wrong in DKs interface to libexiv2 or libexiv2 works different to exiv2. HTH Guenther -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #28 from Guenther M. Erhard <[hidden email]> --- Some more warnings exiftool gives on my test files: "[minor] Ignored empty rdf:Bag list for mwg-rs:RegionList - E-M5_Meta-write.ORF" "[minor] Fixed incorrect URI for xmlns:MicrosoftPhoto - GME15825.ORF" -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
--- Comment #29 from [hidden email] --- Definitively, the problem is not in digiKam. It's in Exiv2 shared lib. As it's annotated in Setup/metadata dialog, writting into RAW file still experimental. It's recommended to use XMP sidecar instead Gilles Caulier -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=368862
[hidden email] changed: What |Removed |Added ---------------------------------------------------------------------------- Latest Commit| |http://commits.kde.org/digi | |kam/2c67e6ffd23d8e7fda2704e | |875378b7f2da20905 Version Fixed In| |5.3.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #30 from [hidden email] --- Git commit 2c67e6ffd23d8e7fda2704e875378b7f2da20905 by Gilles Caulier. Committed on 01/11/2016 at 17:00. Pushed by cgilles into branch 'master'. Internal Libraw updated to 0.18-beta1 with 78 cameras added, floating point DNG support, decode exotic DNG formats e.g. 8-bit DNG, and more metadata parsed while decoding as white balance presets, DNG colordata, vendor specific metadata. See Libraw announcement for details : http://www.libraw.org/news/libraw-0-18-beta1 Related: bug 367640, bug 328321, bug 257737, bug 347010 FIXED-IN: 5.3.0 M +5 -0 NEWS M +1 -5 libs/rawengine/libraw/COPYRIGHT M +230 -235 libs/rawengine/libraw/Changelog.txt M +0 -0 libs/rawengine/libraw/LICENSE.CDDL M +0 -0 libs/rawengine/libraw/LICENSE.LGPL M +4 -5 libs/rawengine/libraw/README A +34 -0 libs/rawengine/libraw/README.DNGSDK.txt M +1 -4 libs/rawengine/libraw/internal/aahd_demosaic.cpp M +1682 -1038 libs/rawengine/libraw/internal/dcraw_common.cpp M +1 -4 libs/rawengine/libraw/internal/dcraw_fileio.cpp M +3 -6 libs/rawengine/libraw/internal/defines.h M +1 -10 libs/rawengine/libraw/internal/demosaic_packs.cpp M +1 -4 libs/rawengine/libraw/internal/dht_demosaic.cpp M +16 -6 libs/rawengine/libraw/internal/libraw_internal_funcs.h M +1080 -551 libs/rawengine/libraw/internal/libraw_x3f.cpp M +1 -3 libs/rawengine/libraw/internal/var_defines.h M +1 -10 libs/rawengine/libraw/internal/wf_filtering.cpp M +29 -21 libs/rawengine/libraw/libraw/libraw.h M +1 -4 libs/rawengine/libraw/libraw/libraw_alloc.h M +10 -32 libs/rawengine/libraw/libraw/libraw_const.h M +5 -8 libs/rawengine/libraw/libraw/libraw_datastream.h M +2 -6 libs/rawengine/libraw/libraw/libraw_internal.h M +67 -28 libs/rawengine/libraw/libraw/libraw_types.h M +3 -6 libs/rawengine/libraw/libraw/libraw_version.h M +1 -5 libs/rawengine/libraw/samples/4channels.cpp M +51 -10 libs/rawengine/libraw/samples/dcraw_emu.cpp M +1 -5 libs/rawengine/libraw/samples/dcraw_half.c M +1 -4 libs/rawengine/libraw/samples/half_mt.c M +1 -4 libs/rawengine/libraw/samples/half_mt_win32.c M +1 -4 libs/rawengine/libraw/samples/mem_image.cpp M +1 -5 libs/rawengine/libraw/samples/multirender_test.cpp M +1 -6 libs/rawengine/libraw/samples/postprocessing_benchmark.cpp M +124 -20 libs/rawengine/libraw/samples/raw-identify.cpp M +16 -5 libs/rawengine/libraw/samples/simple_dcraw.cpp M +2 -5 libs/rawengine/libraw/samples/unprocessed_raw.cpp M +38 -3 libs/rawengine/libraw/src/libraw_c_api.cpp M +458 -100 libs/rawengine/libraw/src/libraw_cxx.cpp M +1 -4 libs/rawengine/libraw/src/libraw_datastream.cpp A +811 -0 libs/rawengine/libraw/src/libraw_xtrans_compressed.cpp [License: UNKNOWN] * The files marked with a * at the end have a non valid license. Please read: http://techbase.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. http://commits.kde.org/digikam/2c67e6ffd23d8e7fda2704e875378b7f2da20905 -- You are receiving this mail because: You are the assignee for the bug. |
Free forum by Nabble | Edit this page |