It appears that in certain environments (homebrew on MacOS) the linker
does not like the -z nodelete option, so handle this differently.
old/legacy-imlib2#8
- configure.ac: Alphabetic order
- Makefile.am: Alphabetic order, no need for nodelete
- loaders.c: Add to known loaders
- loader_y4m.c: Remove some unneeded headers
Prepared using:
```
$ ffmpeg -i test/images/icon-64.png -pix_fmt yuv420p test/images/icon-64.yuv420p.y4m
...
$ ffmpeg -i test/images/icon-64.png -pix_fmt yuv422p test/images/icon-64.yuv422p.y4m
...
$ ffmpeg -i test/images/icon-64.png -pix_fmt yuv444p test/images/icon-64.yuv444p.y4m
...
```
Tested:
(1) correct y4m files
```
$ LD_LIBRARY_PATH=~/proj/imlib2/src/lib/.libs/:${LD_LIBRARY_PATH} IMLIB2_MODULE_PATH=~/proj/imlib2/src/modules/loaders/.libs/ valgrind --leak-check=yes /bin/feh ~/proj/imlib2/test/images/icon-*y4m
==391567== Memcheck, a memory error detector
==391567== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==391567== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==391567== Command: /bin/feh /home/chemag/proj/imlib2/test/images/icon-64.yuv420p.y4m /home/chemag/proj/imlib2/test/images/icon-64.yuv422p.y4m /home/chemag/proj/imlib2/test/images/icon-64.yuv444p.y4m
==391567==
==391567==
==391567== HEAP SUMMARY:
==391567== in use at exit: 297,719 bytes in 1,018 blocks
==391567== total heap usage: 5,151 allocs, 4,133 frees, 871,023 bytes allocated
==391567==
==391567== LEAK SUMMARY:
==391567== definitely lost: 0 bytes in 0 blocks
==391567== indirectly lost: 0 bytes in 0 blocks
==391567== possibly lost: 0 bytes in 0 blocks
==391567== still reachable: 295,703 bytes in 997 blocks
==391567== suppressed: 0 bytes in 0 blocks
==391567== Reachable blocks (those to which a pointer was found) are not shown.
==391567== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==391567==
==391567== For lists of detected and suppressed errors, rerun with: -s
==391567== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```
(2) broken y4m file
Prepared by copying test/images/icon-64.yuv420p.y4m and replacing the "C420jpeg" item in the first line with "Cfoo" (invalid color space).
```
$ LD_LIBRARY_PATH=~/proj/imlib2/src/lib/.libs/:${LD_LIBRARY_PATH} IMLIB2_MODULE_PATH=~/proj/imlib2/src/modules/loaders/.libs/ valgrind --leak-check=yes /bin/feh ~/proj/imlib2/icon-64.yuv420p.y4m
==391699== Memcheck, a memory error detector
==391699== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==391699== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==391699== Command: /bin/feh /home/chemag/proj/imlib2/icon-64.yuv420p.y4m
==391699==
liby4m: Unrecognized colourspace foo
liby4m: Unable to read file's parameter list
liby4m: Failed to parse file header
***** Imlib2 Developer Warning ***** :
This program is calling the Imlib call:
imlib_image_set_changes_on_disk();
With the parameter:
image
being NULL. Please fix your program.
***** Imlib2 Developer Warning ***** :
This program is calling the Imlib call:
imlib_image_get_width();
With the parameter:
image
being NULL. Please fix your program.
***** Imlib2 Developer Warning ***** :
This program is calling the Imlib call:
imlib_image_get_height();
With the parameter:
image
being NULL. Please fix your program.
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 1 (X_CreateWindow)
Value in failed request: 0x0
Serial number of failed request: 15
Current serial number in output stream: 16
==391699==
==391699== HEAP SUMMARY:
==391699== in use at exit: 303,880 bytes in 2,116 blocks
==391699== total heap usage: 3,405 allocs, 1,289 frees, 670,313 bytes allocated
==391699==
==391699== LEAK SUMMARY:
==391699== definitely lost: 0 bytes in 0 blocks
==391699== indirectly lost: 0 bytes in 0 blocks
==391699== possibly lost: 0 bytes in 0 blocks
==391699== still reachable: 301,864 bytes in 2,095 blocks
==391699== suppressed: 0 bytes in 0 blocks
==391699== Reachable blocks (those to which a pointer was found) are not shown.
==391699== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==391699==
==391699== For lists of detected and suppressed errors, rerun with: -s
==391699== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```
Implemented just `_load()` for now.
Summary:
Implements a loader for y4m images. Uses liby4m and libyuv.
Only implements the `_load()` function as of now
Tested:
```
$ ./configure
...
Configuration Options Summary:
Image loaders:
Regular image loaders
GIF.....................: yes
HEIF....................: yes
Y4M.....................: yes
...
$ make -j
...
$ sudo make install
...
$ feh image.y4m
-- image shows up
```
Tested with yuv420p, yuv422p, and yuv444p images.
- Fix clipping to source.
- Fix error when mask from shape is requested but drawable is pixmap.
- Use queried drawable depth, not the context one.
This eliminates the last usage of the context depth in the grabbing
functions.
When using imlib_create[_scaled]_image_from_drawable() with non-zero
source offsets the output image could contain pixels either not set or
copied from uninitialised parts of intermediary pixmap.
Source clipping in imlib_copy_drawable_to_image() was broken and is
already dealt with in __imlib_GrabDrawableToRGBA().
Destination clipping has now been added.
On 1:1 scaling call __imlib_GrabDrawableToRGBA() directly instead of
going through __imlib_GrabDrawableScaledToRGBA().
This fixes 1:1 grabbing of pixmaps.
Non-1:1 pixmaps grabs are still not ok (window grabs are).
__imlib_FileCanRead() suffers from TOCTTOU issues. The file behind the
path it takes as a parameter can change while the function executes, and
also between the function's return and the caller's use of the path.
The function is also unused, so just delete it.