Legacy ImageMagick Discussions Archive

I'm a bit confused, perhaps because it's 4am... but I think the general rule is: int --> float, return the exact value in float, only then convert into the correct quantum. float --> int, first convert into the correct quantum, then return trunc(float+0.5) [and clamp if needed after] 8 --> 16, multi...

Ops, I think broke the conversion from 8-->16

Could you check out?

Well, the integer part is certainly correct since 65535/255=257 The floating point part is more tricky... For example quantum/256.0+0.5 rounds up at 0.5 but it's also correct to round down at 0.5, although it's not usual. So don't change this. If you want the same exact results at the integer versio...

While not being exactly equivalent to the conversion being done in the integer version this new hdri version in actually more accurate : 16bit,8bit_int,8bit_hdri 0,0,0 1,0,0 126,0,0 127,0,0 128,0,0 129,1,1 254,1,1 255,1,1 256,1,1 257,1,1 65406,254,254 65407,255,254 65408,255,255 65409,255,255 65534,...

the integer Image formats I believe automatically clamp when the values are out of range. It is only a rounding problem that needs to be figured out. I think you're right. In fact the conversion from 8->16 bits already works fine in both versions, correctly using the rule: y=65535/255*x It is the o...

Sorry, I was editing my last post while you posted back... Anyway, -clamp won't solve this bias. I think you shouldn't add clamp: that would defeat the purpose of HDRI. This only applies when you're writing into or reading from an integer image format. It is at that exact time that the conversion ru...

fmw42, this is not a bug in reading or manipulating high depth images. HDRI-enabled imagemagick works just fine with OpenEXR for example. I wouldn't even call it a bug... It's a statistically-unsound choice (truncate instead of round) in converting from high depth into low depth. It generates a bias...

I've nailed it, using a small 12 pixel pgm... The conversion from 8-->16 is consistent: input_8bits;hdri_16bits;int_16bits 0;0;0 1;257;257 255;65535;65535 But look at what happens from 16-->8... input_16bits;hdri_8bits;int_8bits 0;0;0 1;0;0 126;0;0 127;0;0 128;0;0 129;0;1 254;0;1 255;0;1 256;0;1 257...

Hello! I know this is an exotic topic, and anyway, it's not exactly a bug, but I noticed a statistic bias in the HDRI enabled version.... I was doing statistics on differences between 8bit and 16bit versions of the same image, to find the standard deviation of the sampling error (should be about 1/1...

I had planned to work on this during the new year break, but morphology got my attention instead. I just never seem to get time otherwise, and lack of people programming IM is the major problem. I will definitely try to help once I have time! I think some of these functions don't need histograms to...

As I said I will give it a try. My main problem right now is I'm doing a university work in HDR image processing, besides my regular daytime job. So I'm a bit short on time... but if I can get some time to understand ImageMagick's framework I'll implement this before September. Otherwise it will hav...

Actually not on gray-level, but on both min-channels-level and max-channels-level.

Sorting an array of a few million elements is trivial, and at most you use as much space as the image itself, for grayscale images, or 1/3 as much for RGB.

Correct, it should be 999999-20000, not 999999-10000 ! Apart from that believe it's all correct, right? I think for an exact algorithm one should not use histograms but go straight into an array the size of the image. Note that since the array would only contain 1 value per pixel, instead of 3, of w...

My proposal for linear-stretch (or let's call it a new name, perhaps) is as follows... Define 2 functions: max(r,g,b){ if ((r >= g) && (r >= b)) return r; if ((g >= r) && (g >= b)) return g; if ((b >= r) && (b >= g)) return b; } min(r,g,b){ if ((r <= g) && (r <= b)) r...

In hind sight, it might have been better to disable the comment part when needed to speed up graphical histograms rather than require it be enabled for textual histograms. But too late now. So I will modify my scripts. You are probably correct... probably more persons are counting on this that coul...