| Age | Commit message (Collapse) | Author | Files | Lines |
|
MagickWand comes with a couple of incompatible API changes in version 7.
|
|
Thanks to Sebastian Pipping for nagging me loudly about this!
|
|
The default locale datetime format string may not suit everyone, this
adds possibility to specify custom format. The format string should be
syntactically conforming to strftime(3).
|
|
A workaround for badly exported images that contain some garbage
at the borders. The amount specifies how many pixels should be shaved
from all borders (i.e. amount of 2 results in 4x4 pixels loss).
Applicable for particular items or whole album (<general> section)
with the following syntax:
<shave amount="1" />
|
|
This works by creating corresponding hidpi image sizes on startup and
letting the machinery generate high resolution images from the source
images (no way to use supplied images). However since browsers expect
exact image dimension multiples for the particular scale factor,
a reference image size (scale factor 1.0x) must be read first, then
cropped to match reference aspect ratio and resized to exact dimensions.
That way pixel-perfect results can be achieved for the chosen scale
factor.
TODO: the CSS background-image: image-set() tags are not supported
on Firefox.
TODO: try the 1.5x scale factor
|
|
This change brings the possibility to tweak resize options using standard
ImageMagick `convert` command syntax. Separate options are offered for
thumbnails.
|
|
This commit brings deeper changes to the image sizes concept. The goal
was to allow more flexible input in resizing vs. supplied files mixed
mode. Instead of hard <noresize> flags the decision whether to resize
or copy an image is now based on threshold. While not 100% universal,
it brings more control regarding image size bounds. Also brings a level
of tolerance for specific errors (off-by-one exports).
Image sizes' rules are a bit simpler, hopefully easier to understand.
A lot can be achieved by combination of thresholds.
|
|
Useful to override previous camera owner name stored in EXIF.
|
|
Both MagickWand and exiv2 needs some initialization and cleanup, move
it to jpeg-utils for clean includes in cgg.c.
Also add explicit exiv2 XMP initialization as stated on
http://dev.exiv2.org/projects/exiv2/wiki/Thread_safety:
"The XMP SDK initialization function is not mutex protected, thus
Exiv2::XmpParser::initialize is not thread-safe. Therefore, multi-threaded
applications need to ensure that this XMP function is serialized, e.g.,
by calling them from an initialization section which is run before any
threads are started."
See also https://bugs.kde.org/show_bug.cgi?id=166424
|
|
Turned out that we shouldn't blindly copy all metadata from the supplied
external EXIF file since they belong to a different image. This includes
image size, JPEG compression parameters, rotation etc.
This commit adds tag filtering so that not all tags are copied, retaining
the important ones from the gallery image.
The list of retained tags is by no means complete and is subject to future
tweaks. For the moment this feature is recommended to be turned off (and
is by default).
|
|
|
|
Users are not really supposed to hit any of them, it would indicate
a programmer mistake otherwise.
|
|
This mode retains given aspect ratio and crops the area from inside of the
source image.
|
|
This change makes thumbnail image sizes more flexible by explicitly
stating the particular image size is a thumbnail. And each thumbnail
image size can have different squared settings.
On the theme side it's now mandatory to specify which thumbnail size
to use (if applicable). This allows us to have different thumbnail styles
for index and album pages.
This commit also removes the <squared_thumbnails> tag from setup.xml
file but retains fallback for ver. 1 setup.xml files.
|
|
There were lots of errors reported for the same issue recently, let's
silence some and only report image copy/resize errors.
|
|
This is a file format break within development branch.
|
|
Some cameras have the Exif.CanonSi.0x000c tag present but set to zero
(raw value). Since this would result in some -128 deg. C, ignore such
values.
|
|
Similar to using supplied timestamps this is useful for fully manual
lenses that don't provide any information to the camera.
|
|
This removes associated ICC profiles and such, though we should
perform proper colorspace conversion to plain (s)RGB first.
|
|
Turned out the Exif.Image.DateTime key may contain original timestamp
in some cases, e.g. when using extracted EXIF data from original image.
Since we can't trust this key has ever been modified by a photo software,
let's modify it together with other keys. It comes with a cost of changing
correct timestamp but we can't really distinguish that.
|
|
In simple crop square mode it's sometimes viable to specify position
of the square. This is vastly useful for portrait pictures so that you
don't crop the head off the body.
|
|
Weird things happened to me in the past while debugging, it's like the
lifetime of returned const strings is unknown and we can't really rely
on them, so let's duplicate them immediately. This will not however fully
solve the issue but rather minimizes the risk.
Need to investigate what's going on, don't really want to start using
mutexes to ensure full thread safety. Moreover we have separate objects
in each thread.
|
|
Turned out these two keys are commonly used as well.
|
|
|
|
Some RAW editors like Adobe products like to include XMP data. Let's
strip them all off (unless disabled).
|
|
Turned off by default, this will copy all data from supplied external
EXIF metadata file back to all generated image files. All user overrides
are still applied on top of it.
Another reason for turning this off is file size concern, target image
files would carry a lot more information that may not be always needed and
would increase total amount of data transferred.
|
|
There are more date-related IPTC tags in the specs but so far
I haven't seen anything else than Iptc.Application2.{Date,Time}Created
|
|
This essentially means faking the datetime, e.g. when you want to mask
original picture date.
This commit also changes little bit of datetime conversion, hopefully
fixing DST issues. Needs more testing.
|
|
Simple datetime shift, including EXIF data modification.
|
|
And change g_str_has_prefix() for key name comparison to g_str_equal()
to prevent potential prefix clashes.
|
|
|
|
For the moment we're using Exif.CanonSi.0x000c key from Exiv2 namespace
since it's an unknown tag to it. This may need little tweaking in the
future when proper naming becomes upstream.
|
|
This brings a new HAS_EXIF define which is present when
EXIF information are available. Templates have been modified
to inform user when not available.
The test for EXIF metadata presence is fairly basic, we only look
for aperture, focal length and exposure time attributes. This might
be a subject to change in the future.
|
|
This allows much greater flexibility from templates regarding
EXIF metadata handling, no more hardcoded symbols. It's possible
to display essentially any attribute known to Exiv2. Please see
http://exiv2.org/metadata.html
This brings two new functions that can be called from templates:
* get_exif_value (exiv2_attribute)
* get_exif_value_fixed (exiv2_attribute)
Both functions take a string argument of metadata attribute name
from Exiv2 namespace. The difference is that get_exif_value_fixed()
does some extra formatting for several basic attributes
(e.g. datetime format).
|
|
|
|
This comes with a cost of decoding full image when only getting image size.
|
|
|
|
|
|
|
|
Silly me, this can be easily done at once.
|
|
Disabled by default, only very simple center crop implemented.
The SQUARED_SIMPLE_SHAVE_AMOUNT constant may be slightly adjusted
according to future experience. It's a really dumb algorithm which
may not be suitable for every picture.
Looking for a fast and smart algorithm to determine image weight center
and radius, i.e. focus on object of interest. The OpenCV's face recognition
features are worth to test and consider, though I fear the speed issues.
|
|
mktime() modifies tm_wday and tm_yday to correct values.
|
|
|
|
|
|
|
|
Also made progress output a little bit nicer
default = 1 thread at once, for safety reasons
I've encountered critical issues with ImageMagick compiled with OpenMP support. Hope that package maintainers are clever.
ShittyMagickWandGenesis(), ShittyMagickWandTerminus() :-)
|
|
|
|
|