Bug 295905 - Width and height info not shown for images
Summary: Width and height info not shown for images
Status: RESOLVED UPSTREAM
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-13 09:50 UTC by Szczepan Hołyszewski
Modified: 2013-08-22 08:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Szczepan Hołyszewski 2012-03-13 09:50:11 UTC
Frankly, I gave the severity "grave" primarily to reflect how annoyed I am by this problem resurfacing AGAIN.

Yes, once again the width and height info in the information panel is not shown for certain images.

Furthermore, it can happen that the info *IS* shown for a file, but *NOT* for a copy of same file in a new directory, which is a strong indication that the dreaded and inexcusable dependency on the directory having been crawled by the obnoxious crawler engine has crept in again. There is absolutely no reason to look this information up in any metadatabase that is compiled once in a freakin' lifetime of the universe. This information is available *IN* the file, and should be taken directly *FROM* the file, period.
Comment 1 Peter Penz 2012-03-13 10:13:49 UTC
I won't add a Dolphin-specific code for reading meta-data. Please feel free to forward this report to kdelibs but I won't start again any discussion on this topic. Also period.
Comment 2 Peter Penz 2012-04-16 13:27:10 UTC
Please provide the following information so that we are able to find out the root-cause of this issue:
- Did you enable Nepomuk? (see system-settings -> desktop-search -> [x] Enable Nepomuk Semantic Desktop)
- Did you enable the file indexer? (see system-settings -> desktop-search -> [x] Enable Nepomuk File Indexer)
- In case both things are enabled: Please disable them, log-out, log-in, start Dolphin and check whether the issue still occurs
- If possible, please attach an image to the bug-report where the information width/height is not shown at all

We can proceed in 2 ways with this issue:
1. You provide the necessary information as user so that we can hopefully find out the root-cause (no matter whether it is in Strigi, Nepomuk, Dolphin, a plugin or whatever)
2. If you want to start technical discussions please do this on kfm-devel@kde.org (= Konqueror + Dolphin mailing-list). BTW: The width/height *is* read from the file in case you've disabled the Nepomuk-stuff. But this reading is not done by Dolphin directly but by a Strigi-plugin.
Comment 3 Szczepan Hołyszewski 2012-04-16 15:35:37 UTC
Short answer: Peter, please, simply never use the Nepomuk stuff for width/height, and always use the "Nepomuk stuff disabled" path. Please.

Long answer: assuming "Nepomuk stuff enabled", 

1. mkdir ~/someDir
2. Blacklist ~/someDir from Nepomuk at system-settings -> desktop-search -> desktop-query -> customize-index-folders. Remember to click Apply.
3. Copy an image to ~/someDir. There. No width/height.

Do you check against the blacklist? Is there even an API for doing that? Do you realize that even if the directory is not blacklisted, Nepomuk can still not have the width/height info because the directory was un-blacklisted moments ago?

Do not ever rely on Nepomuk. Ever. Whatever Nepomuk provides is an extra, a bonus, and is implicitly qualified with "last time I checked", i.e. *it can be hopelessly out of sync with reality*. The same conceptual error used to be there in Strigi jpeg analyzer: it took width/height from extra info (EXIF) rather than the primary source (jpeg header). I fixed that. Unfortunately currently I don't have the time to fix this meta-bug in dolphin. Will you? Please!
Comment 4 Peter Penz 2012-04-16 22:27:55 UTC
Git commit c4c89de6042b48cc21639fd2c9ecded1bf5114b6 by Peter Penz.
Committed on 17/04/2012 at 00:23.
Pushed by ppenz into branch 'KDE/4.8'.

Improve fallback mechanism for KFileMetaDataReaderProcess

In case if a file has no resource-URI, read the file directly
to get the metadata.

M  +46   -34   kio/kfile/kfilemetadatareaderprocess.cpp

http://commits.kde.org/kdelibs/c4c89de6042b48cc21639fd2c9ecded1bf5114b6
Comment 5 Peter Penz 2012-04-16 22:48:58 UTC
Git commit 68fee9e5cc32f3533135fba1035c24773a79d91c by Peter Penz.
Committed on 17/04/2012 at 00:46.
Pushed by ppenz into branch 'KDE/4.8'.

Read the metadata from the file if the Nepomuk indexer is disabled

In this case the context metadata like rating etc. gets merged
with the metadata of the file.

M  +16   -9    kio/kfile/kfilemetadatareaderprocess.cpp

http://commits.kde.org/kdelibs/68fee9e5cc32f3533135fba1035c24773a79d91c
Comment 6 Peter Penz 2012-04-16 22:51:46 UTC
@Szczepan: I fixed the fallback mechanism in kdelibs if there is no metadata available from Nepomuk. So in this case the data gets directly read from the file with the help of the Strigi-plugins. Do you have the chance to test the current 4.8.x branch? Otherwise please let us know after 4.8.3 has been released whether it works as expected now. Thanks.
Comment 7 Szczepan Hołyszewski 2012-04-17 12:08:12 UTC
@Peter: simple steps to trick dolphin into displaying *incorrect* width/height, probably even after your last changes: resize an image with mogrify and reset its modification time to the original with touch -d. Voila, stale info from Nepomuk presented to user. This will always be possible as long as you rely on Nepomuk for file data. I don't think your last changes fix that, and this is a bug, since presenting incorrect information to the user is just never acceptable, ever.

The problem with the design (not necessarily *your* design, I'm talking about the whole stack here) is that it confuses three things - file data, file metadata, user metadata - and treats them all as metadata while they should each be treated differently.

File data and file metadata, collectively called file information, are contained in the file. They may be indexed for quick searching or statistics, but when the user requests information about a single file, it shouldn't be too expensive to get file information directly from the file, and this is what should always be done. In the odd case when a piece of file information is really computationally expensive to extract, cached version may be presented with a clear hint that it might be outdated, and preferably a UI to force refreshing.

User metadata is that information which is not contained in the file, but associated with it by the user - ratings, tags, etc. Do ask Nepomuk for these.
Comment 8 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:19:36 UTC
Resetting assignee to default as per bug #305719
Comment 9 Frank Reininghaus 2013-07-29 11:37:34 UTC
Works for me in KDE 4.10.5.
Comment 10 Szczepan Hołyszewski 2013-08-17 18:23:26 UTC
Sorry to dig up this old corpse, but it is not completely dead yet.

I have .jpg image on a pendrive, for which Dolphin doesn't show width/height (nor F number, saturation or sharpness). The file is a valid JPEG, and if I copy it somewhere else, the missing info appears. Same when I rename the file. But when I rename it back to the original name, the info disappears again.

Repeat: when I rename it back to the original name, the info disappears again.

This means that the info is cached somewhere, keyed on the full path, which is WRONG.

All the information needed to display width/height is in the file, therefore it should be taken directly from the file, not sometimes but every time it is requested, no buts, no exceptions, no secondary considerations. It's really that simple.
Comment 11 Frank Reininghaus 2013-08-21 21:14:26 UTC
Thanks for the update.

Please note that the product "dolphin" of this report is wrong - the meta data part of the information panel has never been a part of Dolphin itself:

(a) Up to KDE 4.9, it used KFileMetaDataWidget from kdelibs. This is still the case now if Dolphin is built without nepomuk-core and nepomuk-widgets headers installed -> "product kio/kfile", I think.

(b) Since KDE 4.10, it uses the new FileMetaDataWidget from the nepomuk-widgets library (basically, it's a copy of the old class which has been improved with some features that could not be added to kdelibs because of the feature freeze) -> product "nepomuk/widgets - FileMetaDataWidget".

Please open a new bug report for the new product if you find meta data-related issues in KDE 4.11.0 or later. I think that this is better than just reassigning this report because bug reports with many comments and different subjects 
are sometimes a bit hard to read.

Thanks for your help!
Comment 12 Szczepan Hołyszewski 2013-08-22 02:35:25 UTC
> Please note that the product "dolphin" of this report is wrong
> - the meta data part of the information panel has never been a part of Dolphin itself

Firstly, width and height of an image is emphatically not metadata. It is just data, plainly and simply.

Secondly, confusing data and metadata is the ESSENCE of this bug, and this confusion is thoroughly implemented in dolphin, therefore the product "dolphin" of this report is very much right.

There are data, and then there are metadata. The heuristic to tell the two species apart is very simple: if you zero some bytes in a file and the file becomes unusable as a result, then the information you erased was data, not metadata. This is very much the case with width and height of a jpeg image: if you zero the corresponding fields in the JPEG header, no software designed to work with jpegs (except perhaps some recovery tools) will be able to open the image and display it correctly. Repeat: width and height is data, not metadata.

And Nepomuk is a metadata thing, not a data thing.

Therefore the decision to use Nepomuk for obtaining an image's width and height *is* the very design error that *will* result in the described symptom resurfacing again and again and again and again and again until Nepomuk actually becomes reliable, which none of us will live to see happen.

> Please open a new bug report for the new product if you
> find meta data-related issues in KDE 4.11.0 or later.

Repeat again: this is a data-related issue, not a metadata-related issue.
Comment 13 Frank Reininghaus 2013-08-22 08:12:04 UTC
(In reply to comment #12)
> > Please note that the product "dolphin" of this report is wrong
> > - the meta data part of the information panel has never been a part of Dolphin itself
> 
> Firstly, width and height of an image is emphatically not metadata. It is
> just data, plainly and simply.

Sorry about not being precise enough. I should have said "The widget that displays data and meta data inside the Information Panel is not, and never has been, a part of Dolphin". It seems that Peter never reassigned the bug though because he also took care of KFileMetaDataWidget and related classes in kdelibs.

> Secondly, confusing data and metadata is the ESSENCE of this bug, and this
> confusion is thoroughly implemented in dolphin, therefore the product
> "dolphin" of this report is very much right.

No, it's not. I agree that it might be a bit confusing that the name of the widget contains "meta data", but it cannot be changed easily. By the way, the data shown by this widget includes things like the file size, permissions, etc.

> Repeat again: this is a data-related issue, not a metadata-related issue.

Repeat again: the class that is responsible for the contents of the Information Panel is not, and never has been, a part of Dolphin. Please leave the report closed now (I'll take UPSTREAM as resolution in the hope that you find this more accurate), and open one for the correct product. Thanks for your understanding.