Exposure Blending tool finalization...

[Gilles Caulier-4]

2009/12/25 Marcel Wiesweg <[hidden email]>:

>
>>
>> All zoom and paning features are controled by QT4::QGraphicView. No
>> more. Code is very simple, but... not very fast.
>
> Yes, it cannot be. In fact, you will get bad performance combined with bad
> quality ;-)
>
>        d->pixmapItem->setPixmap(QPixmap::fromImage(image));
>
> For digikam, we will use DImg, here it's QImage. Doesn't matter.
> What happen when "image" is to be painted at zoom 2.0?
>
> The image is converted to a pixmap. Depending on the underlying graphics
> engine, this implies color format conversion (in the best case to
> ARGB32_Premultiplied, in worse cases e.g. to ARGB8565_Premultiplied or RGB16)
> and, for the case of X.org, transport by Xlib protocol to the server.
> For scaling, in the case of X.org, the data need to be tranferred from the X
> server to the application, converted to a QImage, scaled by a factor of 2.0,
> converted back to QPixmap, and again transferred to the X server, where it is
> finally blitted to the window surface.

But it's the same for Digikam::Dimg excepted that caching pixmap is

- more ingenious. We compute caching pixmap from DImg only when we
need to paint scrollview content.
- We use tiled pixmap, as Gimp and photoshop do.
- faster because we only show what we need to see on scrollview.
- We use a large part of memory to store cache data (70Mb if remember)
- scaling code from imlib2 is really great there.

I suspect that QGraphicView show pixmap inside a QLabel and resize
whole content on the fly (whole Pixmap). This is definitively a bad
way.

Sure it work fast with small image, which is usefull to display with
drawing items (not pixmap) but not really to display a large picture.

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

[Marcel Wiesweg]

> But it's the same for Digikam::Dimg excepted that caching pixmap is
>
> - more ingenious. We compute caching pixmap from DImg only when we
> need to paint scrollview content.
> - We use tiled pixmap, as Gimp and photoshop do.
> - faster because we only show what we need to see on scrollview.
> - We use a large part of memory to store cache data (70Mb if remember)
> - scaling code from imlib2 is really great there.

And we dont have the network roundtrip to the X server and no possibly lossy
color space conversions.

>
> I suspect that QGraphicView show pixmap inside a QLabel and resize
> whole content on the fly (whole Pixmap). This is definitively a bad
> way.

It may be clever and resize only the needed part, but any scaling of a QPixmap
is bad (tm).

>
> Sure it work fast with small image, which is usefull to display with
> drawing items (not pixmap) but not really to display a large picture.

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

[Gerhard Kulzer]

Hi Gilles,
I used the bracketing plugin extensively on my Australia pictures :-) it works great!!!
The only thing missing is an update of the generated and saved HDR with meta-data.

I suggest to automatically copy the meta-data of the 2nd image in the stack to the HDR image. Also, the digikam time stamp should then be updated to exif time. In any view where images are sorted by date, the new image will then appear among the stack of composing images.

Gerhard

On Wed, Dec 23, 2009 at 1:08 PM, Gilles Caulier <[hidden email]> wrote:

(:=)))...

I just commit in kipi-plugins a new widget to zoom in / zoom out / pan
Exposure blending tool preview...

Gilles

2009/12/23 Johannes Wienke <[hidden email]>:

> Am 23.12.2009 12:32 schrieb Gilles Caulier:
>>
>> yes sure... Comment setupdcraw.cpp:110 to be sure...
>
> Ok, forget about the problem. With a compile recompile and disabling ccache
> it works now... No more ccache for me. ;)
>
> Johannes
>
>

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

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

[Gilles Caulier-4]

2009/12/28 Gerhard Kulzer <[hidden email]>:
> Hi Gilles,
> I used the bracketing plugin extensively on my Australia pictures :-) it
> works great!!!
> The only thing missing is an update of the generated and saved HDR with
> meta-data.

Yes, it's partially done.

>
> I suggest to automatically copy the meta-data of the 2nd image in the stack
> to the HDR image.

Why the second one ? If your bracketed stack as more than 3 images
which must be used ?

>Also, the digikam time stamp should then be updated to
> exif time. In any view where images are sorted by date, the new image will
> then appear among the stack of composing images.
>

Yes, this is easy.

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

[Gilles Caulier-4]

2009/12/28 Gerhard Kulzer <[hidden email]>:
> Hi Gilles,
> I used the bracketing plugin extensively on my Australia pictures :-) it
> works great!!!
> The only thing missing is an update of the generated and saved HDR with
> meta-data.
>

Date updated to target image

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

[Gilles Caulier-4]

To all,

The tool is now ready to use in production for me. All remarks from
users have been implemented.

I will prepare a new blog entry about...

Gilles

2009/12/21 Gilles Caulier <[hidden email]>:

> Hi all,
>
> Since few day, i working hard to create a new tool to make pseudo HDR image.
>
> After some try with QtPfsGui code imported and improved as a new
> kipi-plugins (code is in my home dir from KDE svn), I never give a
> right result as HDR creation and Tonemapping. QtPfsGui code is very
> very very experiemental. Only one time, i create successfully an HDR
> image without artefact. This is not enough for me/
>
> I cannot understand why users said that QtPfsGui is a good program.
> Please, if you fell that i'm wrong let's me hear. Perhaps i have a
> simple view of programmer, but at least code speak about : I lost one
> week to review and fix this code to be suitable, readable, and
> maintainable.
>
> It's a shame to writte code like this... but it's another story...
>
> So, after to be tired to play with QtPfsGui code, i thinking to take
> another way : Enfuse.
>
> The idea is simple :
>
> 1/ Define a stack of bracketed images.
> 2/ If Raw images, convert it to TIFF 16 bits with auto-gamma.
> 3/ Auto Align stack with Hugin auto_align_stack command line program.
> 4/ Start pseudo-HDR editor, the famous Enfuse frontend designed by me (:=)))
>
> All is done, excepted step 2, partially implemented. Tool is currently
> suitable with all other images formats as JPEG, PNG, TIFF, etc...
>
> You need to install Hugin and Enblend project to your computer before
> to use this new tool.
>
> Now the screenshots... Champagne please !
>
> 1/ The tool is available in digiKam Tools menu :
>
> http://farm3.static.flickr.com/2657/4203352088_78f8025d41_o.png
>
> 2/ The first stage of the tool is an assistant :
>
> http://farm3.static.flickr.com/2681/4203352164_388c23be82_o.png
>
> 3/ You need first to set-up bracketed images stack :
>
> http://farm3.static.flickr.com/2590/4203352256_91dd0dbd55_o.png
>
> 4/ After that tool is ready to process auto alignment of stack :
>
> http://farm3.static.flickr.com/2629/4202593315_7bd8a6fe66_o.png
>
> 5/ Auto-Alignment can be long... so, take a cup of Champagne to be patient :
>
> http://farm3.static.flickr.com/2596/4203352414_edc73d4d8d_o.png
>
> 6/ "Et Voilà". Auto-Alignment is done. Aligned images are save to temp
> TIFF files :
>
> http://farm5.static.flickr.com/4006/4203352494_49704b8972_o.png
>
> 7/ And now, the best for the end... Let's go to fuse bracketed images :
>
> http://farm3.static.flickr.com/2496/4203352570_b30255d05b_o.png
>
> 8/ Enfuse take a while too, depending of options used... At least,
> result is great (:=))) :
>
> http://farm3.static.flickr.com/2761/4202593625_e03a4d8256_o.png
>
> My TODO List :
>
> - Move this tool from my home KDE svn dir to trunk to be available in
> kipi-plugins 1.1. I will do it soon.
> - Add Raw support.
> - Add a stack of processed images in Enfuse Gui. Selecting one items
> will display it in preview. You can select the best to export in your
> collection.
> - Add some advanced Enfuse options. Here i'm waiting comments form users...
> - Hack last bugs, memory leak, and other joys (:=)))...
>
> Important : this tool is also available as a stand alone application
> "expoblending". It's installed in your usual binary place from your
> computer.
>
> I'm waiting your viewpoints, feedback, critics... etc...
>
> Your servant
>
> Gilles Caulier
>

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

[Gilles Caulier-4]

2009/12/21 Johannes Wienke <[hidden email]>:
> Ok, now that it compiled some comments:
>
> 1. Nice! Great results on first shot. :) Thanks for the tool.
>
> 2. What about adding the ability to generate a preview on a down-scaled
> version of the images? That could speed up the process of finding the right
> parameters.

Johannes,

In trunk, i changed  a lots of code and implemented preview management
with Exposure Blending.

Please, Checkout svn, recompile, and test. Test all cases.

I have done a million of test tody, to be sure that nothing is broken,
but... you know software... regression is regression

At least now, rendering is screen is very  very fast : less than 2
seconds. You can see all enfuse settings changes quickly and
compare... This tool is really great.

Preview use JPEG image (1280x1024). I think it's really enough.

Using Save button, generate target images now. This part take a while
now. But there is no other way of course...

Ah, and I forget : Happy new year.

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