Summary: | No metadata are displayed from non supported Exiv2 file formats | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | ldlafleur |
Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caulier.gilles, metzpinguin |
Priority: | NOR | ||
Version: | 7.3.0 | ||
Target Milestone: | --- | ||
Platform: | Microsoft Windows | ||
OS: | Microsoft Windows | ||
Latest Commit: | https://invent.kde.org/graphics/digikam/commit/69df44c6fc5777252c6a9f00204344a070787e25 | Version Fixed In: | 7.3.0 |
Description
ldlafleur
2020-02-11 16:13:19 UTC
There is no Exif decoder in digiKam core, all is delegate to Exiv2 shared library. Please report this problem to libexiv2 project. Look file already open here : https://github.com/Exiv2/exiv2/issues/236 Gilles Caulier *** Bug 419316 has been marked as a duplicate of this bug. *** *** Bug 420667 has been marked as a duplicate of this bug. *** I reopen this file to be a more generic issues. The solution to be able to handle metadata from non supported Exiv2 files format will be to use ImageMagick identify. I found a way with ImageMagick to extract all recognized metadata from image. For FITS image (not supported by Exiv2) this give something like that: [gilles@localhost FITS]$ identify -format '%[*:*]' ngc6543_optical_B.fits date:create=2021-04-02T08:19:47+00:00 date:modify=2021-04-02T08:19:10+00:00 fits:bitpix=16 / number of bits per data pixel fits:bscale=1 / default scaling factor fits:bzero=32768 / offset data range to that of unsigned short fits:cd1_1=4.44707382411E-06 / Degrees / Pixel fits:cd1_2=-3.14322677056E-06 / Degrees / Pixel fits:cd2_1=-3.14322677056E-06 / Degrees / Pixel fits:cd2_2=-4.44707382411E-06 / Degrees / Pixel fits:colorspc='Grayscale' / PCL: Color space fits:comment=FITS module version 01.01.02.0288 fits:crpix1=2043.50292969 / Reference Pixel in X fits:crpix2=1902.92858887 / Reference Pixel in Y fits:crval1=269.640136719 / R.A. (degrees) of reference pixel fits:crval2=66.6320571899 / Declination of reference pixel fits:ctype1='RA---TAN' / Coordinate Type fits:ctype2='DEC--TAN' / Coordinate Type fits:equinox=2000. / Equinox of Ref. Coord. fits:extend=T / FITS dataset may contain extensions fits:history=PUTAST: Aug 8 11:25:45 2008 World Coordinate System parameters written fits:latpole=0. / Celestial latitude of native pole fits:lonpole=180. / Native longitude of Celestial pole fits:naxis=2 / number of data axes fits:naxis1=3600 / length of data axis 1 fits:naxis2=3600 / length of data axis 2 fits:program='PixInsight 01.08.03.1123' / Software that created this HDU fits:pv2_1=0. / Projection parameter 1 fits:resolutn=300. / PCL: Resolution in pixels per resolution unit fits:resounit='inch ' / PCL: Resolution unit fits:simple=T / file does conform to FITS standard [gilles@localhost FITS]$ I think we will need a new DMetadata C++ wrapper based on ImageMagick API as existing ones based on libheif and libraw... In opposite of 'identify -verbose filename' which take age to give output as histogram and color spaces are parsed, the 'identify -format '%[*:*]' filename' way is very fast... Gilles The ImageMagick C API provide a direct access to indentify tool by this header : https://imagemagick.org/api/MagickWand/identify_8h.html The static method arguments sound like the command lines options. So it must simple to implement a wrapper. Of course, as with DMetadata::ffmpeg wrapper, we will need to re-route the identify output to the Exiv2 format for post process info in digiKam core. Gilles Caulier Removing subscriber per abuse report we received. Git commit 69df44c6fc5777252c6a9f00204344a070787e25 by Gilles Caulier. Committed on 06/04/2021 at 14:09. Pushed by cgilles into branch 'master'. Add metadata extraction support for non supported Exiv2 files. A new ImageMagick wrapper using internally IM::identify C++ API will list all ImageMagick properties and host all information to a dedicated Xmp.IMProperties XMP namespace. Screenshot with FITS astro-photo images taken from NASA/CHANDRA radio-telescope: https://imgur.com/QRHsGOE Related: bug 435231, bug 393408 FIXED-IN: 4.3.0 M +3 -2 NEWS M +1 -0 core/libs/metadataengine/CMakeLists.txt M +7 -0 core/libs/metadataengine/dmetadata/dmetadata.h M +5 -2 core/libs/metadataengine/dmetadata/dmetadata_fileio.cpp C +75 -53 core/libs/metadataengine/dmetadata/dmetadata_imagemagick.cpp [from: core/tests/dimg/magickidentify.cpp - 060% similarity] M +0 -1 core/libs/metadataengine/engine/metaengine.h M +2 -2 core/tests/dimg/magickidentify.cpp M +1 -1 core/tests/dimg/magickloader.cpp https://invent.kde.org/graphics/digikam/commit/69df44c6fc5777252c6a9f00204344a070787e25 Git commit 89fd16a675a68fd84f63299dea53fff3b5e08dee by Gilles Caulier. Committed on 06/04/2021 at 14:53. Pushed by cgilles into branch 'master'. Add FITS file format support in database and image editor Related: bug 435231, bug 393408 M +28 -2 core/app/utils/digikam_globals.cpp M +31 -17 core/libs/database/coredb/coredbschemaupdater.cpp M +2 -0 core/libs/database/coredb/coredbschemaupdater.h https://invent.kde.org/graphics/digikam/commit/89fd16a675a68fd84f63299dea53fff3b5e08dee Maik, I enabled FITS container in database and image editor (RW). In editor, loading image data works, excepted metadata from right sidebar. Same metadata view from album GUI work as expected. In ImageMagick loader we have a readMetadata() call but it sound like nothing is done. Other problem is to save image data as FITS from image editor. ImageMagick plugin is well called but it refuse to encode file with a generic exception: "profile 'icc": 'RBG' : RGB color space not permitted on grayscale PNG" and it's right: we cannot use RGB ICC profile in grayscale image. Original FITS file loaded in image editor is this one (a grayscale FITS image): https://chandra.harvard.edu/photo/2010/sn1979c/fits/m100_optical_R.fits Gilles Maik, >In editor, loading image data works, excepted metadata from right sidebar. Same >metadata view from album GUI work as expected. In ImageMagick loader we have a >readMetadata() call but it sound like nothing is done. I fixed this problem with my last commit in git/master. >Other problem is to save image data as FITS from image editor. ImageMagick >plugin is well called but it refuse to encode file with a generic exception: > >"profile 'icc": 'RBG' : RGB color space not permitted on grayscale PNG" > >and it's right: we cannot use RGB ICC profile in grayscale image. > >Original FITS file loaded in image editor is this one (a grayscale FITS image): > >https://chandra.harvard.edu/photo/2010/sn1979c/fits/m100_optical_R.fits This problem is still present. Can you reproduce ? Gilles Yes, I can reproduce the problem. What I do not understand with ImageMagick, that the problem occurs in png.c, we try to save a FITS image ... Maik We pass "PNG" as the format of the ImageMagick save function. Maik Another thing is that FTS and FIT are not Flexible Image Transport System files and ImageMagick does not recognize the extensions either. Maik Maik, Look on the top/right side of FITS wikipage : https://en.wikipedia.org/wiki/FITS "Filename extension: .fits, .fit, .fts" Gilles Git commit fad897c97e8a06c6461c8957872234ae8c0e8d89 by Maik Qualmann. Committed on 07/04/2021 at 18:02. Pushed by mqualmann into branch 'master'. fix save image in the right format M +1 -0 core/libs/dimg/dimg_fileio.cpp https://invent.kde.org/graphics/digikam/commit/fad897c97e8a06c6461c8957872234ae8c0e8d89 When saving, ImageMagick only accepts FITS and FTS. The FIT format is unknown when saving to ImageMagick. Maik |