We need to run raw_input in modal mode, such that we can return the
text that has been entered as the return value. This makes the use
of "raw_input()" within the pyconsole work as well as makes "help()"
not get stuck (it was blocking on input on stdin).
Fixes the plug-in output to render decimal digit
characters as octal escaped, so they can't be acidentally
combined in preceding escaped sequences. (i.e. the sequence
of values '255, 49' is now rendered as '\377\049' instead of
'\3771')
Thanks Steve Baker for noticing and reporting the issue.
Return "R'G'B'[A] u8" and "TYPE_RGB[A]_8" and babl and lcms formats.
I'm not sure which code triggered the warning about an unhandled
format, but now it handles indexed images too.
The reported size isn't very precise but close enough to get an idea of
what you will get. The problem is that raw files always have some unused
regions that get cropped away later.
Another source of discrepancy can be manual cropping by the user in
darktable, but there isn't much we can do about that.
Before there wouldn't be any intermediate file being written when
darktable sees more than one XMP file. Now the first image in its
temporary database gets exported.
Change file magic matching from using a simple boolean "magic matches"
logic to using a matching quality. The quality is measured by the
number of bytes that matched.
Matching a single file procedure's magics now tries all magics and
returns the best match quality.
Searching a file procedure for a given file now tries all file
procedures and returns the one with the best match quality.
This fixes raw camera files being opened as TIFF, given a better magic
than just the generic TIFF magic is provided.
g_free the lru 'unit' when removed from the cache
and keep track of the list length and last item
while looking for a duplicate already present in
the cache.
Don't skip the first 10 bytes. That code was there to skip the magic
"GIMP_XMP_1" of the old "gimp-metadata" parasite. Instead, properly
check for that magic in xcf_load_image() and pass only the actual XMP
to gimp_metadata_set_from_xmp(). Also remove the +10 hack in file-exr.
"exif-data" parasite
To migrate old "exif-data" parasites to GimpMetadata
an exif-only jpeg file is generated in memory, but its
APP1 marker length was 2 bytes short resulting in a
CRITICAL warning:
** (gimp-2.9:9): CRITICAL **: Directory Photo: IFD exceeds data buffer, cannot read next pointer.
Properly terminating the jpeg with an EOI marker also
gets rid of the WARNING:
** (gimp-2.9:9): WARNING **: JPEG format error, rc = 5
tiff GIMP saved
the plugin unconditionally used to add a TIFFTAG_SUBIFD
whose number_of_sub_IFDs was wrong when the user asked
not to include a thumbnail.
Reloading the file in GIMP resulted in:
** (file-tiff:1): CRITICAL **: Directory SubImage1 with 18761 entries considered invalid; not read.
the icons in the Prototype directory are intended as a
'icon-pool' dedicated for developers, e.g. for solving
Bug 759904
All icons in there a not optimized (e.g. not pixel-perfect),
the are available as vectorial too.
Once they are in use by GIMP they will get all needed optimizations
(Pixel-Perfect, Size.... what is necessary)
Available icons are for symbolical and color icons themes and have 16x16 pixels.
For now we only check if darktable is in PATH, of the right version and
supporting the featuers we need (i.e., Lua scripting). We still want to
have a way to manually specify the path to the darktable installation in
preferences I guess.
Using code from gegl:tiff-load and gegl:tiff-save which has a mode for
local buffering if the input/output streams don't support seeking.
Unfortunately this code is broken and is disabled for now.
Kristian Rietveld