valgrind issue in ctlrender when using unsupported input file format

[michaeldsmith]

a valgrind issue occurs when libtiff is not installed and a TIF file is input to CTL render.

For example, when the command below is used with valgrind

../../ctlrender/ctlrender -force -ctl ../../../unittest/ctlrender/unity.ctl ../../../unittest/ctlrender/bars_photoshop_16_le_interleaved.tif out.tif

The ctlrender command-line output says the input file is not supported:
unable to read file ../../../unittest/ctlrender/bars_photoshop_16_le_interleaved.tif (unknown format).

and the valgrind output is below:

+ valgrind -s --error-exitcode=1 --leak-check=full --track-origins=yes --show-leak-kinds=all ../../ctlrender/ctlrender -force -ctl ../../../unittest/ctlrender/unity.ctl ../../../unittest/ctlrender/bars_photoshop_16_le_interleaved.tif out.tif
==858== Memcheck, a memory error detector
==858== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==858== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==858== Command: ../../ctlrender/ctlrender -force -ctl ../../../unittest/ctlrender/unity.ctl ../../../unittest/ctlrender/bars_photoshop_16_le_interleaved.tif out.tif
==858==
unable to read file ../../../unittest/ctlrender/bars_photoshop_16_le_interleaved.tif (unknown format).
==858== 
==858== HEAP SUMMARY:
==858==     in use at exit: 72 bytes in 2 blocks
==858==   total heap usage: 13 allocs, 11 frees, 95,328 bytes allocated
==858==
==858== 24 bytes in 1 blocks are still reachable in loss record 1 of 2
==858==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==858==    by 0x1240F8: __gnu_cxx::new_allocator<std::_List_node<char const*> >::allocate(unsigned long, void const*) (new_allocator.h:114)
==858==    by 0x123D13: std::allocator_traits<std::allocator<std::_List_node<char const*> > >::allocate(std::allocator<std::_List_node<char const*> >&, unsigned long) (alloc_traits.h:443)
==858==    by 0x12377C: std::__cxx11::_List_base<char const*, std::allocator<char const*> >::_M_get_node() (stl_list.h:438)
==858==    by 0x123023: std::_List_node<char const*>* std::__cxx11::list<char const*, std::allocator<char const*> >::_M_create_node<char const* const&>(char const* const&) (stl_list.h:630)
==858==    by 0x12267D: void std::__cxx11::list<char const*, std::allocator<char const*> >::_M_insert<char const* const&>(std::_List_iterator<char const*>, char const* const&) (stl_list.h:1907)
==858==    by 0x121F35: std::__cxx11::list<char const*, std::allocator<char const*> >::push_back(char const* const&) (stl_list.h:1208)
==858==    by 0x120D46: main (main.cc:457)
==858==
==858== 48 bytes in 1 blocks are still reachable in loss record 2 of 2
==858==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==858==    by 0x123F8C: __gnu_cxx::new_allocator<std::_List_node<ctl_operation_t> >::allocate(unsigned long, void const*) (new_allocator.h:114)
==858==    by 0x123B7A: std::allocator_traits<std::allocator<std::_List_node<ctl_operation_t> > >::allocate(std::allocator<std::_List_node<ctl_operation_t> >&, unsigned long) (alloc_traits.h:443)
==858==    by 0x123584: std::__cxx11::_List_base<ctl_operation_t, std::allocator<ctl_operation_t> >::_M_get_node() (stl_list.h:438)
==858==    by 0x122DD9: std::_List_node<ctl_operation_t>* std::__cxx11::list<ctl_operation_t, std::allocator<ctl_operation_t> >::_M_create_node<ctl_operation_t const&>(ctl_operation_t const&) (stl_list.h:630)
==858==    by 0x1224EF: void std::__cxx11::list<ctl_operation_t, std::allocator<ctl_operation_t> >::_M_insert<ctl_operation_t const&>(std::_List_iterator<ctl_operation_t>, ctl_operation_t const&) (stl_list.h:1907)
==858==    by 0x121E81: std::__cxx11::list<ctl_operation_t, std::allocator<ctl_operation_t> >::push_back(ctl_operation_t const&) (stl_list.h:1208)
==858==    by 0x120D91: main (main.cc:466)
==858==
==858== LEAK SUMMARY:
==858==    definitely lost: 0 bytes in 0 blocks
==858==    indirectly lost: 0 bytes in 0 blocks
==858==      possibly lost: 0 bytes in 0 blocks
==858==    still reachable: 72 bytes in 2 blocks
==858==         suppressed: 0 bytes in 0 blocks
==858==
==858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)