https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #19 from Mirco Miranda ---
(In reply to Martin Kyral from comment #17)
> Thanks for working on this problem. Just to clarify: almost all raw formats
> contain actually two jpg previews: the 160x120 thumbnail (which is not
> usable even as a
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #18 from Mirco Miranda ---
(In reply to Martin Kyral from comment #17)
> Thanks for working on this problem. Just to clarify: almost all raw formats
> contain actually two jpg previews: the 160x120 thumbnail (which is not
> usable even as a
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #17 from Martin Kyral ---
Thanks for working on this problem. Just to clarify: almost all raw formats
contain actually two jpg previews: the 160x120 thumbnail (which is not usable
even as a thumbnail now) and larger jpg preview which is eith
https://bugs.kde.org/show_bug.cgi?id=454206
John Kizer changed:
What|Removed |Added
CC||bafco...@btinternet.com
--- Comment #16 from John
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #15 from Mirco Miranda ---
(In reply to Mirco Miranda from comment #13)
> This way there would be two subformats: raw (default) and jpg.
> I have to check if it's possible for readers. The Qt doc is contradictory:
> the list of subformats s
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #14 from Mirco Miranda ---
(In reply to Mirco Miranda from comment #13)
> This way there would be two subformats: raw (default) and jpg.
Unfortunately it's not possible to set subtype in QImageReader.
--
You are receiving this mail becau
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #13 from Mirco Miranda ---
(In reply to Martin Kyral from comment #12)
> Browsing folders with images is now usable again. However, viewing of an
> image still uses QtRaw which is a) slow b) generates ugly previews.
I was rereading this bug
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #12 from Martin Kyral ---
Thumbnailing was fixed by this commit:
https://invent.kde.org/graphics/gwenview/-/commit/0bcb8b3a9f408475645b569efd3cb007fd0e0e52
Browsing folders with images is now usable again. However, viewing of an image
stil
https://bugs.kde.org/show_bug.cgi?id=454206
Candid Dauth changed:
What|Removed |Added
CC||cdauth+bugs.kde.org@cdauth.
|
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #11 from Martin Kyral ---
Created attachment 171952
--> https://bugs.kde.org/attachment.cgi?id=171952&action=edit
Patch to use KDCraw over QtRaw
Patch to use KDCraw over QtRaw
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #10 from Martin Kyral ---
Build of gwenview patched to prefer KDCRaw (Fedora 40 only):
https://copr.fedorainfracloud.org/coprs/mkyral/gwenview/
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #9 from Martin Kyral ---
After some time I looked at the issue again and got some success: the breakage
by the kimageformats update was apparently caused by kimageformats somehow
affecting the formatHint value, when I hardcoded the format va
https://bugs.kde.org/show_bug.cgi?id=454206
vylu changed:
What|Removed |Added
CC||lukev...@gmail.com
--
You are receiving this mail becau
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #8 from Martin Kyral ---
Just to have a glimpse: I was extracting the embedded hi-res jpeg image using
dcraw -e (the method kdcraw uses as well) from 150 raws from 16mpx Olympus. It
took under 500ms. Compare it to the Qt Raw plugin which tak
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #7 from Martin Kyral ---
(In reply to Martin Kyral from comment #6)
> The config option seems perfectly fine to me. Let the user decide that's
> best for them.
>
> The problem is, that KDCraw fucntionality is apparently broken (maybe by
> k
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #6 from Martin Kyral ---
The config option seems perfectly fine to me. Let the user decide that's best
for them.
The problem is, that KDCraw fucntionality is apparently broken (maybe by
kimageformats 5.99) for quite a while. So, the KDCraw
https://bugs.kde.org/show_bug.cgi?id=454206
Mirco Miranda changed:
What|Removed |Added
CC||mirco...@gmail.com
--- Comment #5 from Mirco Mi
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #4 from Martin Kyral ---
Another downturn is that while with KDCraw you get the image straight from the
camera, with Qt Raw plugin the image looks different, rather dull and
underexposed as the demosaicing algorithm and colour science is pro
https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #3 from Martin Kyral ---
By regression I mean the feature is virtually unusable.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=454206
Martin Kyral changed:
What|Removed |Added
CC||sine.nom...@centrum.cz
--- Comment #2 from Marti
https://bugs.kde.org/show_bug.cgi?id=454206
Andrej Halveland changed:
What|Removed |Added
Ever confirmed|0 |1
Version|22.04.1
https://bugs.kde.org/show_bug.cgi?id=454206
aron...@gmail.com changed:
What|Removed |Added
Summary|Unusable performance with |Slow performance with RAW
22 matches
Mail list logo
