Change debian-branch from debian/master to debian/latest

releasing package babl version 1:0.1.106-2

releasing package babl version 1:0.1.106-1

debian/control.in: Set Rules-Requires-Root: no

Update standards version to 4.6.2, no changes needed.

Changes-By: lintian-brush
Fixes: lintian: out-of-date-standards-version
See-also: https://lintian.debian.org/tags/out-of-date-standards-version.html

Set upstream metadata fields: Bug-Database, Bug-Submit.

Changes-By: lintian-brush

Update lintian override info format in d/libbabl-0.1-0.lintian-overrides on line 2, 4.

Changes-By: lintian-brush
Fixes: lintian: mismatched-override
See-also: https://lintian.debian.org/tags/mismatched-override.html

autopkgtest: Update for renamed pkgconfig file: babl-0.1 instead of babl

New upstream release

Update upstream source from tag 'upstream/0.1.106'

Update to upstream version '0.1.106'
with Debian dir 562092e7b513326aa8d6d85c1ed9885e38cc82de

New upstream version 0.1.106

release 0.1.106

LUT: speed up 3bpp->4bpp LUT

Keep alpha (0xff) as computed rather than stripping and reapplying.

LUT: avoid zeroing alpha in 1bpp to 4bpp LUT

Fixing issue #92.

spaces: built-in RGB to XYZ matrices for default spaces

Babl uses matrices which have been bit-optimized - which is a time consuming
task done at every startup. As reported in now fixed issue #67.

LUT: disable when running on big-endian systems

We are crashing due to endian assumptions - we now only try to do the LUT
optimizations on little endian - no functionality is lost on big-endian
though conversion might be a tad slower. Hopefully fixing issue #91

post release version bump

release 0.1.104

NEWS: update

meson: bump minimum meson version to 0.55.0

As per issue #87 this is the minimum we can build with - and 0.56.x is
available in debian stable which we is used as a bar for inclusion.

babl: make space remodelling array dynamic

Thus fixing issue #89

We protect this behind a mutex, initialization of color managed code from
multiple threads have been known to trigger babl races in GEGL/GIMP code.

babl: make naming more defensive against overflow

Not neccesary while the static strings are 512 bytes, in regular
use we might however want to reduce this to 256bytes.

babl-format: make more more defensive

LUT: make LUTs default to on

The BABL_LUT environment variable still controls whether it is enabled, to
turn off the LUT usage set BABL_LUT=0.

LUT: handle with 4bpp associated aplha to 4bpp straight alpha conversions

LUT: (temporarily) opt out of conversions from R'aG'a'B'aA u8 formats

LUT: initialize LUTs from 4bpp with full alpha

Use alpha=255 in seeding of premultiplied - this might not be enough
we might also have to disassociate and reassociate alpha during conversion.

build: post release version bump

build: release 0.1.102

NEWS: update

LUT: do not use LUTs by default

The code marking LUTs as available for fishes is now protected behind an
environment variable BABL_LUT if it is set, the LUT code is re-enabled.

meson: post release version bump

release 0.1.100

NEWS: update

babl: limit LUT creation for 4→8 and 4→16 bpp further.

Looking at LUT conversion code, we are clearly only supporting
converting from "u8" (to "u16" or "float" respectively).

Conversions such as "YA half" to "R'G'B'A float" for instance would be
completely broken (it was trying to use only one byte of the "YA half",
assumed it was "u8" and transform it to "float"). This is why the sample
image in #85 was appearing on display as more transparent than it should
when converted to 16-bit floating point grayscale image.

babl: make LUT from 2bpp to 4bpp totally generic.

The deleting of the first byte when creating the LUT, then copying the
first byte from source to destination, worked for cases such as "YA u8" to
"RGBA u8" but it would not work for say:

* "Y half" to anything: in such a case, deleting the first byte in LUT's
  content, when creating it, we are basically deleting source's color
  information!
* "YA u8" to "Y float": in such a case, when copying the first byte, at
  conversion time, we are destroying the result color (which didn't need
  any copying of alpha channel as there is no alpha channel in the
  result).
* And so on.

In such cases, it's just better to include everything in the LUT, in a
totally model-agnostic way. In some cases, the alpha channel will be
stored in the LUT, in others, not. But it's not really a problem. It
doesn't even make the LUT bigger; if anything, it makes the LUT creation
and the conversion calculus simpler, hence faster.

babl: LUT, only exclude associated alpha when copied

NEWS: update

babl: narrow conditions for doing LUT conversion

We can do LUTs where the LUT depends only on the 24first bit - for some
formats this ends up including half of the alpha, which is OK when
3->4bpp conversions copy the last 8bits.

babl: LUT from 3bpp to 4bpp must add a fully opaque alpha.

For instance, conversion from "RGB u8" to "RGBA u8". With previous code,
the resulting color was right but the pixel was fully transparent.

Issue #85: Troubles opening 16-bit floating point grayscale files.

All current LUT conversion and creation clearly assume that we are
operating on 1 byte per channel (the flag we use right now to determine
if we may have a LUT is even called `is_u8_color_conv`). So let's
enforce this.

Otherwise we might end up with problems such as in issue #85, where we
convert from or to "YA u16", which is still under 4bpp but not 1bpc. As
a consequence, the first byte of the alpha only was copied and the rest
(including the second alpha byte) was used as belonging to the color
components.

Of course, we can update this code later to also support such cases
(taking into account the source and target alpha size), but for now,
let's simply exclude these.

babl: fix LUT from grayscale to RGBA images.

Images from "Y'A" to "R'G'B'A" for instance would end up completely
transparent because we were not reporting the alpha channel from the
source to destination buffer.

babl: don't create LUT for destination formats with premultiplied colors.

This is a different issue than previous commit, but was revealed by
fixing the bug. So in a way, it's a followup.

When the destination format uses premultiplied colors, we would end up
with a LUT where all colors in the table are (0, 0, 0) since we store
them with alpha = 0. We could also generate them with alpha = 1, but
then we'd have to special-case the conversion step, re-multiplying each
pre-multiplied value with the real alpha, etc. So instead, I just bypass
these conversion cases and don't create LUT for these.

For the record, we had this case on GIMP when rendering u8 images to
display, since it would require for instance a LUT from R'G'B'A u8 to
cairo-ARGB32 (Cairo's ARGB32 being pre-multiplied with alpha). So the
whole image would render black (even though, when color-picking colors,
we'd see pixels' colors are not black).

Note that this bug existed before, but was simply hidden by the bug
fixed in the previous commit (since conversion was done twice: first
with LUT, then through usual conversion paths, the second conversion was
hiding the broken LUT conversion).

Issue #84: do not process color conversion twice.

Until now babl_fish_lut_process_maybe() was always returning 0, even
when a LUT existed, hence a LUT-based conversion happened.

This was bad, first because it was inefficient (the point of the LUT is
that we didn't have to process through usual conversion code paths). But
worse: when the source and destination buffers were the same, we would
end up getting wrong result (since we'd have the source converted
in-place, then re-converted, hence double conversion!).

This was the reason for issue #84 (see screenshot showing very wrong
colors because of double conversion).

bin: fix size of dest memory.

I guess I was lucky I never got a crash for out-of-bound memory access.

Rework _babl_mkdir ()

Use babl utility to iterate over directory contents

Use LoadLibraryW

This makes it possible to load modules in path names having characters
outside of the ANSI codepage

Use the newer SHGetKnownFolderPath instead of the deprecated SHGetFolderPathA

SHGetKnownFolderPath is available since Vista

Unify variables for Windows and non-Windows in fish_cache_path ()

Make mk_ancestry () / mk_ancestry_iter () work without fixed-size buffers

Make fish_cache_path () return a string allocated on the heap

Add overflow check helpers

Make use of the libc wrappers

Add a few babl libc wrappers

Add the following wrappers:

* babl_fopen
* babl_rename
* babl_remove
* babl_mkdir
* babl_stat

And the following util:

* babl_dir_list

On Windows, the wrappers internally convert from UTF8 to UTF16 and
call the wide char routines, that way the string need not be limited
to the ANSI character set. Outside of Windows the wrappers are no-op.
babl_dir_list is implemented using opendir / readdir on non-Windows
and _wfindfirst64 / _wfindnext64 on Windows.

Add two functions for converting between UTF-16 and UTF-8 on Windows

Simpler way to get the module HANDLE

Also works in case of static compilation

update -dependency for wrap builds babl.pc -> babl-0.1.pc

Use secure URI in Homepage field.

Changes-By: lintian-brush
Fixes: lintian: homepage-field-uses-insecure-uri
See-also: https://lintian.debian.org/tags/homepage-field-uses-insecure-uri.html

Issue #83: improve babl_space_get_rgb_luminance() docs.

One of GIMP layer modes was using wrongfully these coefficients on
non-linear data (see gimp#3471). It was not clear from babl docs whether
babl was returning wrong coefficients for non-linear spaces, or whether
we were supposed to only ever use these coefficients on linear data.
This is the second case. So let's make the in-code docs clearer.

releasing package babl version 1:0.1.98-1

Bump Standards-Version to 4.6.1

debian/libbabl-0.1-0.symbols: Add new symbol

New upstream release

Update upstream source from tag 'upstream/0.1.98'

Update to upstream version '0.1.98'
with Debian dir 84208dc67ca6027df8aee915475679ea93d72657

New upstream version 0.1.98

Add debian/upstream/metadata

Update meson.build

Fix Issue #80

post-release version bump

meson, NEWS: release 0.1.98

babl: add babl_gc

The LUT garbage collection was running ad-hoc as a side effect of processing,
this is problematic since it could trigger during processing of other threads
that might be using or freeing the same fish leading to races. The new babl_gc
function is to be called from the main thread, at times when processing is not
occuring, calling babl_gc is not neccesary in short lived commandline tools
and similar.

releasing package babl version 1:0.1.96-1

Update changelog

Don't install newly introduced bin/babl yet

Drop patch applied upstream

New upstream release

Update upstream source from tag 'upstream/0.1.96'

Update to upstream version '0.1.96'
with Debian dir 3d9913af4b14396c9919981df2d2490021699e16

New upstream version 0.1.96

icc: make bounds protection more robust

Further improvements to issue #78

ICC: verify validity of data-ranges for ICC tags

Fixing issue #78

post release version bump

release 0.1.96

meson: remove unneded check: true

This check meant to check if we are in a git checkout or a tarball
caused failures when building from tarballs. Hopefully fixing issue #77.

post-release version bump

release 0.1.94

NEWS: update

meson: fix export_packages for generate_gir

This is required in order for babl to link properly in vapigen.

C.f. https://gitlab.gnome.org/Infrastructure/gimp-macos-build/-/commit/22fc8dafa3e5edc065c035b12024bb7ebb35801a
last file

-Wimplicit-fallthrough add commit according to gcc doc.

main args not used.

Fix warn in CHECK_CONV_FLOAT

-Wsign-compare babl-memory

-Wold-style-declaration

-Wsign-compare conversions.c

Fix warning: -Wsign-compare babl-fish-path

babl-lut-verify: warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]

babl_fish_path: comparison of integer expressions of different signedness

Fix warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]

bin: profile-aware babl format defaults.

Instead of always defaulting to "R'G'B' float", if a input/output
profile was set, check if it's CMYK, grayscale or RGB.

The defaults are:
* For a CMYK profile: "CMYK float"
* For a grayscale profile: "Y' float"
* For anything else (or no profile): "R'G'B' float"

babl: fix typos in error strings.

bin: add -r/--intent for setting the rendering intent on the CLI tool.

bin: show source format in verbose/default output