is myself, but I don't have gcc-5.1 set up. If you clamp itor-
>width to be >= 0, does the problem go away>
Taahir Ahmed
signature.asc
Description: This is a digitally signed message part.
--
Don't Lim
> Yes, there is. If it ran forward we would overwrite our data. Read the code
> again and try to understand what it does.
>
> * Spoiler ahead *
> The image has 3 channels, darktable uses 4.
My apologies, I don't know how I missed that. My original patch used the same
loop.
Taahir
sig
Looks good. I've tested it on big- and little-endian images, and both
load fine. Some comments:
1) This was missing from my original commit, but the pfm export code
at src/imageio/format/pfm.c also needs a similar treatment. It
always exports as little-endian, which is fine, but it
(Sorry for the re-send -- I forgot to copy to the mailing list)
Well, the closest thing to a standard that there is specifies this behavior
[1]. In addition, the previous behavior was platform dependent. If you ran
it on a big-endian platform, it would open all pfms as big-endian.
PFM images of
and look correct. No normalization is performed, so some
pfms can be hard to control with the base curve and tone curve modules,
which seem to assume that all values lie in the [0,1] interval.From ded24c8d4ecd7a4ecdfcd6197dd65ddb7c25722c Mon Sep 17 00:00:00 2001
From: Taahir Ahmed
Date: Sat, 16
that for several months (I have a
renderer that only outputs big-endian pfms), but never quite got around
to it.
Taahir Ahmed
signature.asc
Description: This is a digitally signed message part.
--
One dashboard for server
I recall having a similar error, unrelated to darktable. The problem may be
with one of the /dev/ati* devices -- it either needs to be world
readable/writable, or the user accessing needs to have a certain capability
[1]. Unfortunately, I've forgotten precisely which capability it was.
T
