Bug 129902 - HTML gallery : resize pictures in constant area instead of size max [patch]
Summary: HTML gallery : resize pictures in constant area instead of size max [patch]
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Generic-HTMLGallery (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-27 14:14 UTC by Frédéric COIFFIER
Modified: 2017-05-04 18:49 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 3.2.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric COIFFIER 2006-06-27 14:14:06 UTC
Version:           0.1.0 (using KDE KDE 3.5.3)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 4.1.1 (Gentoo 4.1.1) 
OS:                Linux

Currently, a size is given and each pictures are resized to have its max edge length = size.
But, if the picture is a panorama (where width is very bigger than height), the scaling gives a very small picture.

In fact, the better way could be to have a constant area (for example, resized width * resized height = size^2). So all pictures have the same number of pixels.
In the case of 4/3 photos, it changes nothing but panoramas are correctly resized.

In kipi-plugins/htmlexport/generator.cpp, I use the following code :

#include <math.h>

...

				// Process full image
				{
					if (mInfo->fullResize()) {
						double size=(double)mInfo->fullSize();
						int newwidth = (int)sqrt((size*size*(double)image.width())/(double)image.height());
						int newheight = (int)(size*size/(double)newwidth);
						image=image.smoothScale(newwidth, newheight, QImage::ScaleFree);
					}
Comment 1 Aurelien Gateau 2006-07-05 11:56:05 UTC
I see the use of your patch, but the main goal of limiting the image size is to make sure the image fits in the screen. I don't see how we could have both. Any idea someone?
Comment 2 Frédéric COIFFIER 2006-07-05 13:28:08 UTC
I agree... we can't be sure the image will fit the screen (even if with 4/3 photos, it should be the case). Secondly, if we resize pictures to 1024 pixels max, it won't fit in a 800x600 screen.

So, the best solution is to add an option to select the resize type : max size or area constant (but again an option and again an option to document...)
Comment 3 Achim Bohnet 2006-07-06 00:18:10 UTC
AFAIR, heigth and width of the <img> tag overrules actual image size.
So how about a using  Frédéric algorithm and resize via <img> tag.
Then we can add a 'fit to screen' and 'full size' option to the web page.
These options either load different html files or modify <img> tag's options dynamicly.

Achim -- just brainstorming
Comment 4 caulier.gilles 2008-12-08 09:55:21 UTC
Aurélien,

What's news about this file ?

Gilles Caulier
Comment 5 x3ri7yz02 2010-01-28 12:48:23 UTC
I would like to see some improvements to the way HTML Export handles re-sizing of images and will vote for this bug.  

Preparing for a presentation today, I specified a maximum size of 1024.  This was fine for landscape images (made nice use of screen real-estate).  But for portrait-orientation images, allowing 1024 long meant they spilled off the screen and I had to scroll to show the whole image.  I could reduce the maximum size variable, but then all the landscape images are smaller too.

Perhaps if you could specify BOTH maximum height and maximum width?  This would allow easy re-sizing of images to exact desired specifications.
Comment 6 Petri Damstén 2011-09-13 07:49:44 UTC
I think resizing should be consistent across kipi plugins (now Maximum dimension is used). Could there be a widget with original size, quality, resize options that could be used everywhere? Resize code could be also shared.
Comment 7 caulier.gilles 2011-12-22 15:38:44 UTC
Frédéric,

Do you see comment #6 from Petri ?

Can you update your patch against git/master ?

Gilles Caulier
Comment 8 Shashank 2013-04-25 12:37:24 UTC
The features talked about in this bug have been implemented in 3.2.0, the bug can be closed.