SUMMARY CR3 images from Canon EOS M6 Mark II are displayed correctly BUT most items in the "Metadata > EXIF > No filter" list on the right such as Exposure Bias/Compensation, Exposure Program, Lens Model, etc., are missing. (ExifTool shows these items are included in the RAW files in question.) Digikam DOES successfully display these Metadata > EXIF items in CR2 images from a Canon EOS M5 camera. STEPS TO REPRODUCE 1. Open image from EOS M6 Mark II camera. 2. Open Metadata > Exif viewer on right. 3. In the Metadata viewer on the right, click the triangle, select "No filter", then click on Settings. 4. In the Embedded Image Information Management list, click "Select all". 5. Click OK to return to the image. Repeat above steps for an older camera, e.g., EOS M5. OBSERVED RESULT Many Metadata EXIF items shown for the older camera are missing for the M6 Mark II EXPECTED RESULT The list of EXIF data should be much more extensive for the M6 Mark II. SOFTWARE/OS VERSIONS Windows: Windows 10 Home, ver. 1903 ADDITIONAL INFORMATION digiKam 7.0.0-beta3, Feb 10 2020
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