[digikam] [Bug 368862] New: Thumbnails for Olympus raw (ORF) in albumview are blurred

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 368862] Thumbnails for Olympus raw (ORF) in albumview are blurred

bugzilla_noreply
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.
12