[Bug 145198] New: light-table should also work with the full image

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         
           Summary: light-table should also work with the full image
           Product: digikam
           Version: unspecified
          Platform: Debian stable
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: Light Table
        AssignedTo: digikam-devel kde org
        ReportedBy: arnd.baecker web de


Version:            (using KDE KDE 3.5.5)
Installed from:    Debian stable Packages

In order to really compare the quality (like sharpness) it
is in my opinion essential that the light-table can also work
with non-scaled images (i.e. like the image editor);
Presently a reduced-size version of the image is used.

Gilles reply (in http://bugs.kde.org/show_bug.cgi?id=145159) was:
> for performance reasons, this cannot be changed, especially with RAW files.
> Use  Editor instead.
> If you want to toggle to editor from Light Table,
> use the preview panel pop-up >menu.

> I think this is a non-sense to use the full image in Light Table.
> This tool will be used to judge images and delete the wrong shots.

Still, I think that a 100% view is needed in the light-table.
Maybe something as proposed by Frank in #16
of http://bugs.kde.org/show_bug.cgi?id=140131
a possible solution, also from the users perspective?
The idea is to replace the pixmap in the background
(maybe from a certain zoom-level on) after zooming in.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From caulier.gilles gmail com  2007-05-10 10:27 -------
Actually, the implementation use the preview extraction mechanism from multithreaded File IO management of Marcel. This part use Qt image interface, not Digikam::Dimg.

Added a new option in LT GUI to handle the full image is trivial, but the multithreaded File IO management need to be patched to load the full image with Qt and not the reduced version.

Important : loading the full image with Qt have limitations :

- It's Slow (of course), especially with huge image (TIFF/PNG)
- It's do not support RAW image.
- No color management. The image is always displayed under sRGB color space.
- No feedback during loading.

In fact, we cannot reproduce the same way to manage image file with Image Editor under Lt using Qt...

Note than i think than color management is not necessary with LT.

Solution : using DImg instead Qt in LT.

Marcel, give me your viewpoint. Thanks in advance

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From marcel.wiesweg gmx de  2007-05-10 21:57 -------
We have a number of options here, we need to know what we want.

Using QImage is preview is good because converting to pixmap is faster, and we only need 8bit, no CM. Preview loading is currently optimized for the preview.

What are the requirements of LT? Do we need 16bit? Do we need CM?
If we do not need neither 16bit nor color management, QImage is still a good format. This is even more true if loading the full image is only an option, e.g. offered at high zoom rates (I could imagine that for preview as well, btw).

Then this would mean loading the full image, with optional progress feedback, but only to 8bit. Loading with DImg in 8bit, then converting to QImage. No problem.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From arnd.baecker web de  2007-05-10 23:37 -------
> What are the requirements of LT? Do we need 16bit? Do we need CM?
> If we do not need neither 16bit nor color management, QImage is still a good format. This is even more true if loading the full image is only an option, e.g. offered at high zoom rates (I could imagine that for preview as well, btw).


Presumably 16Bit and Color Management are not needed.
If there is a way to load the full size image in the background,
and to display that from a certain zoom-level on,
this would of course be fantastic -
The light-table would feel as fast as right now,
but offer the full size view ``just in time''.
(I think that picasa does something like this, at
least there is a short message "Refining", when
selecting and zooming into an image).

And yes: it might be also useful for the preview
(and maybe even for the image editor itself?)

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From Julien.Narboux inria fr  2007-05-11 09:54 -------
I do not understand the technical details, but I think that would be nice if the pictures in digikam were everywhere an 'abstraction'. I mean that it would be a function which displays the picture either preview or full size depending on the time. First the preview is displayed, then the real full size with CM when it is ready. It seems to be the way it is done in some other software such as iphoto for instance.

Best,

Julien
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Fabien-5]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From fabien.ubuntu gmail com  2007-05-16 11:41 -------
I just tried for the 1st time the light table. It looks really nice.
But, I fully agree with Arnd : if we can't see the full size picture, it's not possible to compare the sharpness and quality of 2 pictures...
I hope it will be possible to do that, even if it's slower.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From caulier.gilles gmail com  2007-05-16 16:25 -------
Marcel,

Light Table need a new option in configuration panel to solve this B.K.O file to not use the picture preview extraction. If this option is enable :

1/ With JPEG/TIFF/PNG files, the Qt image loaders must be used as well.

2/ With RAW files, use an half decoding preview. Today, i have separated the implementation in libkdcraw (kdraw.cpp) to get RAW preview : one to extract embedded JPEG only, one to decode an half image of RAW picture.

    static bool loadEmbeddedPreview(QImage& image, const QString& path);

    static bool loadHalfPreview(QImage& image, const QString& path);

3/ In all case LT do not limit the preview size to a specific value. I propose to use a zero value to not limit the preview size with LoadingDescription.

What do you think about ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From marcel.wiesweg gmx de  2007-05-16 23:49 -------
I have a patch on my computer that uses the DImg loaders and then converts to QImage. This was very easy to implement because the preview loading class inherits from the normal loading code, and non-raw images can be shared with the image editor in the cache. RAWs are loaded as half-size images in 8-bit mode. We also get interruptable loading when using DImg. The cost is a bit more memory and memory copying. Do you want to test, or shall I commit?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From caulier.gilles gmail com  2007-05-17 00:13 -------
Marcel,

Well, post your patch in this B.K.O file. Me, Arnd, Fabien, Mick can test it and report performance test.

Note : if we use DImg to load image data, why continue to use Qt like image container in LT ??? all is benefit to use Dimg in this part especially about performance (no need post conversion to Qt) and we have too a fast algorithm to scale image...

Also, if in the future, we want support Color Management in LT, we can do it... but this is not a priority actually.

Your viewpoint ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From marcel.wiesweg gmx de  2007-05-17 17:52 -------
The primary reason currently I thought is that per default, the preview is used, which is faster than the high-quality preview I suggest above most notably for RAW and JPEG images.

I you want to leave that and always use the high-quality preview:

I thought that PreviewWidget is based on QImage, but this is not true, you designed it image image format independent.

The fastscale algorithm does not support 16-bit. I do not know if this is a matter of writing some lines of code, or if the algorithm itself will not really support it.
We can easily support scaling 8-bit DImgs with FastScale. Currently, the high-quality preview is always 8 bit.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From marcel.wiesweg gmx de  2007-05-17 17:55 -------
Created an attachment (id=20608)
 --> (http://bugs.kde.org/attachment.cgi?id=20608&action=view)
Patch adding a higher quality preview loading option

Patch as described above.
Note this also patches LightTablePreview to always use the new option.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From arnd.baecker web de  2007-05-17 20:46 -------
Great! I applied the patch and everything works fine.
Concerning the performance, it works fast enough for me,
once the images are loaded (does not feel slower than
before...)
However, the drag-and-drop is very slow (especially the first time),
So I think that loading the full-size image should be done in two
steps: first the quick one as right now (without the patch),
and in a background thread the full one is loaded
(maybe later even with color-management).

In terms of the implementation this is of course much more
complicated and requires a bit of book-keeping and
memory management, but as also mentioned by Julien in #4 above,
this seems to be the way as the speed problem is also solved in other
applications.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From mikmach wp pl  2007-05-18 20:12 -------
Dnia pi�tek 18 maj 2007, Arnd Baecker napisa�:
> ------- Great! I applied the patch and everything works fine.

Where is the patch? I didn't get notification through mail. I'd like to
test it on some high quality images from work (48MB TIFs).

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From caulier.gilles gmail com  2007-05-18 20:17 -------
Mik,

The patch is in the B.K.O file...

http://bugs.kde.org/attachment.cgi?id=20608&action=view

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From mikmach wp pl  2007-05-19 09:48 -------
> The patch is in the B.K.O file...
> http://bugs.kde.org/attachment.cgi?id=20608&action=view


Thanks. Looks like my mailbox provider is playing time games again, I've
got mail with link to Marcel patch several hours after Arnd's mail.
Whatever.

Tested it with big images and didn't notice time performance hit. Of
course it goes through RAM faster than 6-year old through chocolate bar
but it was also earlier the case. One unpleasant thing: with very low
zoom values scaled images look really ugly. Is it possible to turn on
smoothing for low zoom values (or use preview version as Arnd
suggested)?

Really great work :)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

> Tested it with big images and didn't notice time performance hit.

Does it also take some time, until the images  get displayed
after a drag-and-drop from the thumb-bar to the two panels
of the light-table?

> One unpleasant thing: with very low
> zoom values scaled images look really ugly. Is it possible to turn on
> smoothing for low zoom values

I don't think I see this kind of effect - could
you maybe attach a screen-shot?

> (or use preview version as Arnd suggested)?

Hmm, this was more meant for a quick display
until the full image is loaded in the background -
usually it takes the user a few seconds to
move to the place of interest and in the mean time
the full image could be loaded and displayed to
replace the preview variant.

Best, Arnd

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From arnd.baecker web de  2007-05-19 12:14 -------
> Tested it with big images and didn't notice time performance hit.


Does it also take some time, until the images  get displayed
after a drag-and-drop from the thumb-bar to the two panels
of the light-table?

> One unpleasant thing: with very low
> zoom values scaled images look really ugly. Is it possible to turn on
> smoothing for low zoom values


I don't think I see this kind of effect - could
you maybe attach a screen-shot?

> (or use preview version as Arnd suggested)?


Hmm, this was more meant for a quick display
until the full image is loaded in the background -
usually it takes the user a few seconds to
move to the place of interest and in the mean time
the full image could be loaded and displayed to
replace the preview variant.

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From caulier.gilles gmail com  2007-05-19 12:39 -------
>Tested it with big images and didn't notice time performance hit. Of
>course it goes through RAM faster than 6-year old through chocolate bar
>but it was also earlier the case. One unpleasant thing: with very low
>zoom values scaled images look really ugly. Is it possible to turn on
>smoothing for low zoom values (or use preview version as Arnd
>suggested)?

Yes. You see a title side effect generated by the new fastScale algorithm from Antonio. I have surprized than nobody have seen this problem before. I have discovers it many weeks ago (:=)))

To have already investigated about this problem, i'm sure than it's a FastScale implementation failure. If i use Qt:smoothScale instead, all is fine (but more slow of course). This problem only appear to high zoom level. This is not relevant of JPEG compression artifact. Try with a TIFF or PNG image. It's the same.

Nota : if we use DImg::scale implementation, all work fine.

I have pinged Antonio about this problem, but I have no recieve a response yet.

Marcel, like FastScale algorithm sound like very simple to understand, we can try to with it (:=)))

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From arnd.baecker web de  2007-05-19 13:09 -------
Ah, so you are talking about *large* zoom values, i.e. 1200% etc.?!
I.e., is this the one already discussed in
http://bugs.kde.org/show_bug.cgi?id=140131
#10, #11, #12, ...
In #26 Antonio provided a fix, and I thought it was gone -
But, yes, at 1200% it is visible but not at 120%, it seems

The reason I did not see that is that
for images with 270 x 363 pixels a maximal zoom of 1200% is
possible, while for 3456 x 2304  the maximum is 148%!
(We discussed the reason for this some time ago, but
I forgot; still I find it not intuitive, why
the maximal zoom depends on the image size ...)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145198         




------- Additional Comments From caulier.gilles gmail com  2007-05-19 14:05 -------
>Ah, so you are talking about *large* zoom values, i.e. 1200% etc.?!
>I.e., is this the one already discussed in
>http://bugs.kde.org/show_bug.cgi?id=140131
>#10, #11, #12, ...
>In #26 Antonio provided a fix, and I thought it was gone -
>But, yes, at 1200% it is visible but not at 120%, it seems

No Arnd, This is not the same problem. the dysfunction is in the algorithm, not in the  preview tile mechanism.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel