Am 10.02.2016 um 21:01 schrieb Roman Lebedev:
> So i have accidentally stumbled upon those samples today,
> finally reproduced the issue, and I *might* have just fixed this issue in
> git master (commit 81bc3cf56328184ae8b4db4e4ee5a7859f553d82)
>
> Now both images (export_000598.tif and exportt_00
On Fri, Dec 11, 2015 at 3:35 PM, Ben Suttor wrote:
Hi.
> Okey, the YCbCr colorspace is the issue here. Different compression
> modes make no difference, but exporting them to rgb24 works.
> I found a thread where ffmpeg devs (i guess) claim their YCbCr tifs
> are correct but several programms wou
Okey, the YCbCr colorspace is the issue here. Different compression
modes make no difference, but exporting them to rgb24 works.
I found a thread where ffmpeg devs (i guess) claim their YCbCr tifs
are correct but several programms would read them wrong.
I have an other file which darktable manages
2015-12-10 15:51 GMT+01:00 Ben Suttor :
> 2015-12-10 11:14 GMT+01:00 Tobias Ellinghaus :
>> Am Donnerstag, 10. Dezember 2015, 02:40:16 schrieb Ben Suttor:
>>> I found a post in the mailing list archive which describes the exact
>>> problem I have, see below. I also have lots of tifs in one folder,
2015-12-10 11:14 GMT+01:00 Tobias Ellinghaus :
> Am Donnerstag, 10. Dezember 2015, 02:40:16 schrieb Ben Suttor:
>> I found a post in the mailing list archive which describes the exact
>> problem I have, see below. I also have lots of tifs in one folder,
>> sometimes darktable can load the file but
Am Donnerstag, 10. Dezember 2015, 02:40:16 schrieb Ben Suttor:
> I found a post in the mailing list archive which describes the exact
> problem I have, see below. I also have lots of tifs in one folder,
> sometimes darktable can load the file but most of the time it just crashes.
> Also a tif seems
