I've done (still baking it) a small hack to show the zoom numbers in the
main view, always referred to the real image size (not the previewed size). By default digikam uses preview images, and showing smaller images than the actual ones at 100% confuses the user (or at least confuses me). for more info, I provided some screenshots here: http://mail.kde.org/pipermail/digikam-devel/2008-August/020456.html If the image zoom is larger than 1.0, ie, if it's larger than the preview size, it also shows the label "magnified". Then the user knows he's not seeing the real image quality Thus, if you enable showing scaled down images, and then select 100%, you'll see the preview image same size as the orignal image, but a label saying "magnified" will let you know there's a zooming going on, and thus there's quality diminishing. The label dissappears if the zoom level is reduced. The next screenshot shows how it works: http://www.ugarro.com/tmp/proposedSolution.png Please let me know if you like the way of fixing or not. Also, I'd love if you let me know where you'd prefer this code to go. Right now I'm hacking the code right into digikamapp, with: int realZoom=(int)(zoom*100.0*factor); d->statusZoomBar->setZoomSliderValue((int)size); d->statusZoomBar->setZoomTrackerText(zoom<=1?i18n("zoom: %1%", realZoom):i18n("zoom: %1% (magnified)", realZoom)); But it may not be the place to do this right. So I'd appreciate any input on this before I do any further code in code that will not be used. Best regards, Unai Garro _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Dnia Sunday 03 of August 2008, Unai Garro napisał:
> If the image zoom is larger than 1.0, ie, if it's larger than the > preview size, it also shows the label "magnified". Then the user knows > he's not seeing the real image quality > > Thus, if you enable showing scaled down images, and then select 100%, > you'll see the preview image same size as the orignal image, but a label > saying "magnified" will let you know there's a zooming going on, and > thus there's quality diminishing. The label dissappears if the zoom > level is reduced. The next screenshot shows how it works: > http://www.ugarro.com/tmp/proposedSolution.png Too complicated for user. Don't know if possible but everywhere zoom factor should show number relative to real size of image. m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from ugarro@gmail.com
> Too complicated for user. Don't know if possible but everywhere zoom
> factor should show number relative to real size of image. > Eh? it's exactly what my patch is doing. it shows the zoom factor relative to the real size of the image. If you call "real size" to the file size at least. Digikam currently shows it versus the preview size, not versus the real size. Not sure if I explained it right. Go Settings->Configure Digikam -> Album View Settings-> and disable "Embedded preview loads full image size". It should be disabled by default (digikamrc removed) Now open any image, and set zoom to 100%. See the size. Now, right click and select "edit". It will open with showfoto. Set showfoto to 100% too. It's much larger, right? Well, my patch makes both be the same when the zoom factor is set to 100%. But if you see at 100%, the image in digikam (not in showfoto) is smudged, because it uses a preview. So, I have added the detail (magnified) to make it non-confusing. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Dnia Monday 04 of August 2008, Unai Garro napisał:
> > Too complicated for user. Don't know if possible but everywhere zoom > > factor should show number relative to real size of image. > > Eh? it's exactly what my patch is doing. it shows the zoom factor > relative to the real size of the image. If you call "real size" to the > file size at least. > > Digikam currently shows it versus the preview size, not versus the real > size. > > Not sure if I explained it right. Go Settings->Configure Digikam -> > Album View Settings-> and disable "Embedded preview loads full image > size". It should be disabled by default (digikamrc removed) > > Now open any image, and set zoom to 100%. See the size. Now, right click > and select "edit". It will open with showfoto. Set showfoto to 100% too. > > It's much larger, right? Well, my patch makes both be the same when the > zoom factor is set to 100%. But if you see at 100%, the image in digikam > (not in showfoto) is smudged, because it uses a preview. So, I have > added the detail (magnified) to make it non-confusing. OK, sorry. Now I understand. Good feature but label may be misleading. I am not sure if this comment is necessary at all. m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from ugarro@gmail.com
Attached the patch that does what I mentioned. The "(Magnified)" label
is easy to remove if wanted. Since I did the hack in digikamapp, I had do do a few mods in digikamview to allow it read real and preview image sizes. But the rest of the patch is straightforward, and it only affects to the label shown in the percentage. It doesn't even touch the position of the scroll. If there are better ways to do this please let me know. Else have fun and hope you apply the patch. I don't have an svn account anymore since I requested dropping it. Best regards, Unai Index: digikam/digikamview.cpp =================================================================== --- digikam/digikamview.cpp (revision 841643) +++ digikam/digikamview.cpp (working copy) @@ -522,7 +522,14 @@ group.writeEntry("InitialAlbumID", 0); } } - +int DigikamView::previewWidth() +{ + return d->albumWidgetStack->imagePreviewView()->previewWidth(); +} +int DigikamView::previewHeight() +{ + return d->albumWidgetStack->imagePreviewView()->previewHeight(); +} void DigikamView::showSideBars() { d->leftSideBar->restore(); @@ -1416,6 +1423,11 @@ } } +ImageInfo DigikamView::getImageInfo() +{ + return d->albumWidgetStack->imagePreviewView()->getImageInfo(); +} + void DigikamView::slotImageAddToLightTable() { if (d->albumWidgetStack->previewMode() == AlbumWidgetStack::PreviewAlbumMode) Index: digikam/digikamview.h =================================================================== --- digikam/digikamview.h (revision 841643) +++ digikam/digikamview.h (working copy) @@ -64,6 +64,9 @@ void hideSideBars(); void setThumbSize(int size); void toggleShowBar(bool); + int previewWidth(); + int previewHeight(); + ImageInfo getImageInfo(); signals: Index: digikam/imagepreviewview.h =================================================================== --- digikam/imagepreviewview.h (revision 841643) +++ digikam/imagepreviewview.h (working copy) @@ -66,7 +66,6 @@ const ImageInfo &next = ImageInfo()); ImageInfo getImageInfo() const; - void reload(); void setImagePath(const QString& path=QString()); void setPreviousNextPaths(const QString& previous, const QString &next); @@ -99,10 +98,10 @@ void slotPanIconSelectionMoved(const QRect&, bool); void slotPanIconHiden(); -private: - +public: int previewWidth(); int previewHeight(); +private: bool previewIsNull(); void resetPreview(); void zoomFactorChanged(double zoom); Index: digikam/digikamapp.cpp =================================================================== --- digikam/digikamapp.cpp (revision 841643) +++ digikam/digikamapp.cpp (working copy) @@ -2286,8 +2286,22 @@ void DigikamApp::slotZoomChanged(double zoom, int size) { - d->statusZoomBar->setZoomSliderValue(size); - d->statusZoomBar->setZoomTrackerText(i18n("zoom: %1%", (int)(zoom*100.0))); + //We first calculate the zooming factor + //due to showing the scaled down preview + + ImageInfo info=d->view->getImageInfo(); + QSize dimms=info.dimensions(); //We have hte real file's image dimensions here + + int previewWidth=d->view->previewWidth(); + int previewHeight=d->view->previewHeight(); + //Now we calculate the scale factor due to using a preview + float factor=AlbumSettings::instance()->getPreviewLoadFullImageSize()?1:(float)previewWidth/(float)dimms.width(); + + //And calculate the zoom factor relative to the real image size + int realZoom=(int)(zoom*100.0*factor); + + d->statusZoomBar->setZoomSliderValue((int)size); + d->statusZoomBar->setZoomTrackerText(zoom<=1?i18n("zoom: %1%", realZoom):i18n("zoom: %1% (magnified)", realZoom)); } void DigikamApp::slotTogglePreview(bool t) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from ugarro@gmail.com
Unai Garro a écrit :
> I've done (still baking it) a small hack to show the zoom numbers in the > main view, always referred to the real image size (not the previewed > size). By default digikam uses preview images, and showing smaller > images than the actual ones at 100% confuses the user (or at least > confuses me). for more info, I provided some screenshots here: > http://mail.kde.org/pipermail/digikam-devel/2008-August/020456.html > > If the image zoom is larger than 1.0, ie, if it's larger than the > preview size, it also shows the label "magnified". Then the user knows > he's not seeing the real image quality > > Thus, if you enable showing scaled down images, and then select 100%, > you'll see the preview image same size as the orignal image, but a label > saying "magnified" will let you know there's a zooming going on, and > thus there's quality diminishing. The label dissappears if the zoom > level is reduced. The next screenshot shows how it works: > http://www.ugarro.com/tmp/proposedSolution.png > > > Please let me know if you like the way of fixing or not. > > I agree it would be nice to display the percentage relative to the original image. In addition, it would be even better to load the original image on the fly when the user selects a zoom factor which makes the image larger than the preview. It would be less confusing for the user than the "magnified" label. I think if someone zoom in, it means he wants to see the real image quality. Best wishes, Julien _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from ugarro@gmail.com
> In addition, it would be even better to load the > original image on the fly when the user selects a zoom factor which > makes the image larger than the preview. > I agree with you. Loading the full sized image after the preview image reaches its 100% would be so nice. I wanted to do that, but not sure if that will be acceptable due to speed reasons. Whoever made the scaled previews default must have found that the application was slow with full sized images. Can any maintainer confirm if this sort of change would be acceptable? I so, I could try doing it that way. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
> I agree with you. Loading the full sized image after the preview image > reaches its 100% would be so nice. > I wanted to do that, but not sure if that will be acceptable due to > speed reasons. Whoever made the scaled previews default must have > found that the application was slow with full sized images. > > Can any maintainer confirm if this sort of change would be acceptable? > I so, I could try doing it that way. Gilles, ¿any chances I'll get any response from you? Do you actually care about this patch or not? Or is there some better way to get patches in these days? I don't have much time for coding and I'm using it for your little project. I tried asking you in irc around 10 times by now and you seem not to hear a thing. Really, if digikam development works that day these days, it used to be more responsive project a couple years back. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
---------- Forwarded message ----------
From: Gilles Caulier <[hidden email]> Date: 2008/8/5 Subject: Re: [Proposed solution] zoom factor error To: Unai Garro <[hidden email]> 2008/8/5 Unai Garro <[hidden email]>: > >> I'm currently very busy with real life. >> >> If you want to contribute properlly, use bugzilla post your patch and >> let's _constructive_ comments at the right place. if i don't respond >> to irc you must understand that i can be busy (i have my main car >> broken) or i work on other important place. No need to perturb me to >> spam my irc account... Unforget that i work on my free time for open >> source. It's not a real job. Perhaps are you more friendly with pro >> software as Bibble pro (like i can read on your irc post !) >> >> > > Please accept my apology for being rude, but the digikam's source code > README clearly reads: > > "If you want contribute to digiKam developments do email at : > [hidden email]" > In fact posting a new file in bugzilla report the file content to digikam-devel by default. I will change README file to be more clear. But unforget that the usual way is to use bugzilla to post report + patch. nothing is lost, instead than a mailing list where messages will diseapear speedly into a large flux of mails. Also, Mailling list attachement is limited to 40 Kb. into bugzilla 1Mb... See bugzilla as a queue of task to do. Imagine that i going to vacation for a while, your message can be lost definitily. With Bugzilla, nothing is lost, others developers/users can test your patch etc... > And that's what I did. No bugzilla comments. Maybe that needs a change? > > I thought my comments were rather friendly: > http://mail.kde.org/pipermail/digikam-devel/2008-August/020456.html > And I submitted the patch to the lists, just like it was suggested: > http://mail.kde.org/pipermail/digikam-devel/2008-August/020483.html > > I needed a response from you. Other coders refuse to accept any patches > until you say go. And I cannot code more unless I know you will like the way > I'm going to do it. I may waste 2 weeks of code just to hear there's > somebody else doing it in a different way. it happenned to me in digikam in > the past, remember? yes, of course (:=))) >and it's annoying. > > The fact that I praise other software doesn't mean I don't praise digikam as > I have done several times in my blogs, even in my last post around 5 hours > ago. > > http://www.kdedevelopers.org/node/3592 > > I think having good references in other applications is good. Bibble is a > good reference for speed and batching, but lightzone is much better > reference for editor. But both of them suck for sorting photos, while > digikam is great at it. Each got their strengths. I use what suits me for > each thing. > > Anyway, I want it to beat commercial software. I coded digikam quite a bit > in the past. You know that: Hot pixels plugin, the 16 bits conversion, > allowing scrolling of images, autodeletion of images after download and a > few others. > > Please don't take me wrong. I'm trying to use my holidays in the best way > possible and that's trying to help the project. > But I don't want to duplicate efforts. If you don't say "go" to something, I > may be duplicating work you or somebody else are doing. It happenned in the > past with some patches I had for digikam. And I don't have much time for > that. No, there is no duplicates for your zooming patch > > I've seen your post on the raw importer for example. I didn't know it > existed, and I was trying to do something very similar with batch > capabilities. Are you interested on that? Yes, but yet. And it's a huge work to do. In fact i have plan to do more better : a Batch Queue manager. But this require new data hosted by Database, and it's can only do into KDE4. > And in my interests there's also improving raw decoding speed by getting rid > (if possible) of dcraw executable. Some people have managed already making a > library out of it. Would you be interested in something like that too? yes. forget libopenraw which still unsuitable to process demosaicing. I have planed to patch libkdcraw to use libraw instead dcraw. libraw implement 90% of dcraw features, excepted all color management options. But we can use multithreading as well withouit to fork dcraw in a separate process (which is more long to init). If you is interrested to patch libkdcraw, let's me hear. Nite that the libkdcraw to patch is KDE4, not KDE3. About your patch, it's against KDE3 or KDE4 ? The code sound fine for me (not yet tested here) Andi, can you test Unai patch's on your computer and give me your feedback ? Gilles Caulier Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from ugarro@gmail.com
Gilles Caulier wrote:
> > About your patch, it's against KDE3 or KDE4 ? The code sound fine for > me (not yet tested here) > I keep forgetting kde3 is still maintained sorry. The patch is against svn trunk, thus kde4. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Gilles Caulier-4
2008/8/5 Gilles Caulier <[hidden email]>:
> ---------- Forwarded message ---------- > From: Gilles Caulier <[hidden email]> > Date: 2008/8/5 > Subject: Re: [Proposed solution] zoom factor error > To: Unai Garro <[hidden email]> > > > 2008/8/5 Unai Garro <[hidden email]>: >> >>> I'm currently very busy with real life. >>> >>> If you want to contribute properlly, use bugzilla post your patch and >>> let's _constructive_ comments at the right place. if i don't respond >>> to irc you must understand that i can be busy (i have my main car >>> broken) or i work on other important place. No need to perturb me to >>> spam my irc account... Unforget that i work on my free time for open >>> source. It's not a real job. Perhaps are you more friendly with pro >>> software as Bibble pro (like i can read on your irc post !) >>> >>> >> >> Please accept my apology for being rude, but the digikam's source code >> README clearly reads: >> >> "If you want contribute to digiKam developments do email at : >> [hidden email]" >> > > In fact posting a new file in bugzilla report the file content to > digikam-devel by default. I will change README file to be more clear. > > But unforget that the usual way is to use bugzilla to post report + > patch. nothing is lost, instead than a mailing list where messages > will diseapear speedly into a large flux of mails. Also, Mailling list > attachement is limited to 40 Kb. into bugzilla 1Mb... > > See bugzilla as a queue of task to do. Imagine that i going to > vacation for a while, your message can be lost definitily. With > Bugzilla, nothing is lost, others developers/users can test your patch > etc... > >> And that's what I did. No bugzilla comments. Maybe that needs a change? >> >> I thought my comments were rather friendly: >> http://mail.kde.org/pipermail/digikam-devel/2008-August/020456.html >> And I submitted the patch to the lists, just like it was suggested: >> http://mail.kde.org/pipermail/digikam-devel/2008-August/020483.html >> >> I needed a response from you. Other coders refuse to accept any patches >> until you say go. And I cannot code more unless I know you will like the way >> I'm going to do it. I may waste 2 weeks of code just to hear there's >> somebody else doing it in a different way. it happenned to me in digikam in >> the past, remember? > > yes, of course (:=))) > > >>and it's annoying. >> >> The fact that I praise other software doesn't mean I don't praise digikam as >> I have done several times in my blogs, even in my last post around 5 hours >> ago. >> >> http://www.kdedevelopers.org/node/3592 >> >> I think having good references in other applications is good. Bibble is a >> good reference for speed and batching, but lightzone is much better >> reference for editor. But both of them suck for sorting photos, while >> digikam is great at it. Each got their strengths. I use what suits me for >> each thing. >> >> Anyway, I want it to beat commercial software. I coded digikam quite a bit >> in the past. You know that: Hot pixels plugin, the 16 bits conversion, >> allowing scrolling of images, autodeletion of images after download and a >> few others. >> >> Please don't take me wrong. I'm trying to use my holidays in the best way >> possible and that's trying to help the project. >> But I don't want to duplicate efforts. If you don't say "go" to something, I >> may be duplicating work you or somebody else are doing. It happenned in the >> past with some patches I had for digikam. And I don't have much time for >> that. > > No, there is no duplicates for your zooming patch > >> >> I've seen your post on the raw importer for example. I didn't know it >> existed, and I was trying to do something very similar with batch >> capabilities. Are you interested on that? > > Yes, but yet. And it's a huge work to do. In fact i have plan to do > more better : a Batch Queue manager. But this require new data hosted > by Database, and it's can only do into KDE4. > >> And in my interests there's also improving raw decoding speed by getting rid >> (if possible) of dcraw executable. Some people have managed already making a >> library out of it. Would you be interested in something like that too? > > yes. forget libopenraw which still unsuitable to process demosaicing. > I have planed to patch libkdcraw to use libraw instead dcraw. > Forget to said than libraw is available at this place: http://www.libraw.org/ If you patch libkdcraw to support libraw, you must lets dcraw as well and include libraw as optionnal until we hack it indeep. Best Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Free forum by Nabble | Edit this page |