| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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() :-)
|
|
|
|
|
