pmxbot IRC Log Viewer

[07:06:27] <travis-ci> [travis-ci] python-pillow/Pillow#1532 (master - 0b82dac : Hugo): The build passed.

[07:06:27] <travis-ci> [travis-ci] Change view : https://github.com/python-pillow/Pillow/compare/5dc418b8de95...0b82dacea280

[07:06:27] <travis-ci> [travis-ci] Build details : http://travis-ci.org/python-pillow/Pillow/builds/35703715

[20:02:10] <MathFox> A simple question: Does PILlow support 48 bits (3*16) RGB TIFFs, or can it be made to support that format?

[22:59:13] <wiredfool> MathFox: not out of the box. there are some ifdefs in there that might make it work.

[22:59:52] <wiredfool> MathFox: but it would definitely be something that would need detailed testing and likely debugging.

[23:00:12] <MathFox> Is it worth some time to look into it and verify things work...

[23:01:00] <MathFox> I am consulting with a government organization that has shown "some interest"

[23:01:22] <MathFox> And I am willing to spend some time on it

[23:01:52] <MathFox> (also on getting the sign-offs to open source the cone)

[23:02:32] <wiredfool> I see.

[23:05:07] <MathFox> I will have to make a business case though

[23:05:40] <MathFox> Personally I would not mind bug fixing after my stint there

[23:05:41] <wiredfool> I'm looking for it now, but not seeing it.

[23:06:14] <wiredfool> What sort of image operations would they be needing?

[23:06:14] <MathFox> I haven't seen a quick define in the code eihter

[23:07:02] <MathFox> what they need is loading uncompressed R16G16B16 TIFFs and a pixel walk

[23:07:40] <MathFox> I think I can hack that outside PIL in a week or so

[23:08:21] <wiredfool> Ok. That's probably doable pretty easily

[23:09:18] <wiredfool> I'm seeing soem float64, I wonder if that's what I was remembering

[23:09:46] <MathFox> There also is some INT32 code....

[23:10:11] <wiredfool> yeah, there's code for I16 and I32, but those are single channel

[23:10:32] <wiredfool> in many permutations of signedness and endianess

[23:10:59] <MathFox> But I think Pillow would benefit from Uint16 support...

[23:11:45] <wiredfool> I16 is unsigned, I16S is signed

[23:13:44] <MathFox> There are differences between import and internal formats

[23:14:00] <wiredfool> So, the core storage and unpacking are in Storage.c, Pack.c, and Unpack.c. Convert.c is also important

[23:14:33] <wiredfool> Plain old tiffs will wind up using a raw decoder, which is essentially an unpack routine.

[23:14:45] <MathFox> I might need to define a new internal storage format too

[23:14:50] <wiredfool> Then something in PixelAccess.c and PyAccess will have to be done for pixel level access

[23:14:58] <MathFox> to use full dynamics

[23:17:08] <wiredfool> Yeah, there's the im->image8|32 pointers, which are essentially pointers to a row in the image

[23:17:59] <MathFox> My question is, would you seriously consider a contribution (patch) for "RGB48" support?

[23:19:23] <wiredfool> Yes.

[23:21:01] <MathFox> I expect a rejection at first... with motivation ;-) Despite having testers at my side saying "it seems to work"

[23:21:31] <wiredfool> Ah. Things that will help:

[23:22:12] <wiredfool> Sample images that are redistributable, preferrably in both endianesses

[23:22:21] <wiredfool> Tests that pass with those images

[23:22:38] <MathFox> *nod*

[23:23:24] <wiredfool> Plain old tiff is fine, Read only is fine as well

[23:23:50] <wiredfool> Libtiff and writes are bonuses, and probably not that hard.

[23:24:16] <wiredfool> with the caveat that I think native tiff support is broken with any compression,

[23:26:29] <MathFox> My caveat is that any test images I am likely to get will be in the 40-60 MB size range (think 300 dpi scans)

[23:26:54] <wiredfool> Crop them small then

[23:27:01] <wiredfool> at least for distribution

[23:27:39] <wiredfool> Testing with them is probably going to expose some of the memory intensive decisions in the tiff support.

[23:27:47] <MathFox> Keep them uncropped only for local performance tests ;-)

[23:28:07] <MathFox> I might need to take a look at that too....

[23:28:19] <wiredfool> yeah. I'd hope that we could load and save one of those on a 512mb machine

[23:28:39] <wiredfool> but I'm not going to check in a monster like that

[23:29:03] <MathFox> My client has 32 GB... and 32 bits python.....

[23:29:18] <wiredfool> oh, also support for toarray/fromarray for sci/numpy

[23:29:28] <wiredfool> that seems .. interesting

[23:29:33] <tdsmith> not to tout the competition, but tifffile.py was written for microscopy so it's good at getting multi-plane 16-bit TIFFs into numpy arrays, if it's helpful to have something to compare with

[23:30:06] <tdsmith> not sure how it handles TIFFs saved by tools other than microscopy software ;)

[23:30:53] <wiredfool> yeah, but how does it do decompressing jpeg2000s?

[23:30:57] <wiredfool> oh wait...

[23:31:07] <tdsmith> ha

[23:32:02] <MathFox> I have found some I16 scans somewhere in a repository dumped om me... leading seems to work

[23:32:23] <MathFox> loading

[23:37:59] <wiredfool> I16 should be reasonably well shaken out.

[23:39:46] <MathFox> I'll take a more detailed look at the source code over the week...

[23:40:10] <MathFox> It's pas bedtime for me now :-)

[23:40:14] <wiredfool> ok

[23:40:40] <wiredfool> feel free to ask questions, here or email. I do idle here, but it can be hours...

[23:41:48] <MathFox> One fundamental question I have is "signed vs. unsigned"

[23:42:47] <wiredfool> I don't think that you'll see signed RGB, but whenever I say I don't expect somethign in a tiff, it shows up.

[23:43:17] <MathFox> in RGB channel intensity is (mathematically seen) a scaled [0.0..1.0]

[23:43:51] <wiredfool> as is single channel. The representation varies, however.

[23:44:30] <MathFox> *nod*

[23:44:58] <MathFox> And there is other colour spaces...

[23:46:08] <wiredfool> Yes. 90% of the work will be getting RGB to work.

[23:46:23] <wiredfool> L*ab might take some.

[23:48:01] <MathFox> I am off for some sleep... I hope no nightmares.

[23:48:21] <MathFox> You are likely to see me in here over the coming weeks

[23:48:49] <wiredfool> ok

Log file Viewer

Help | Karma | Search:

#pil logs for Friday the 19th of September, 2014