Skip to content
This repository has been archived by the owner on Oct 4, 2020. It is now read-only.

Expose raw buffer #19

Closed
campaul opened this issue May 21, 2015 · 10 comments
Closed

Expose raw buffer #19

campaul opened this issue May 21, 2015 · 10 comments
Milestone

Comments

@campaul
Copy link
Member

campaul commented May 21, 2015

No description provided.

@SamWhited
Copy link
Member

@campaul Is this not fixed by to_buffer, or was this issue about the original non-RGB data? Needs context.

@campaul
Copy link
Member Author

campaul commented Jun 3, 2015

This is referring to the not dcraw processed data.

@SamWhited
Copy link
Member

I'm not sure that we need this; I think we should be the higher level API, this strikes me as a lower level thing (which you can get through the LibRaw API if you want to go down to that level).

@SamWhited
Copy link
Member

I just had another change of heart on this; maybe we do want to support this, because if you're a researcher using photos to analyse something you probably want a way to get the raw bayer moire data (and you shouldn't have to dig down into libraw land to do it). I'll probably change my mind again tomorrow though.

@SamWhited SamWhited added this to the v1.0.0 milestone Jul 19, 2015
@KelSolaar
Copy link

I pinged you about exactly that on FreeNode! I would actually need access to the non-debayered raw data (brut sensor data) that I would hook into Numpy arrays for further explorations.

@SamWhited SamWhited modified the milestones: v0.5.0, v1.0.0 Sep 17, 2015
@paalge
Copy link
Contributor

paalge commented Oct 27, 2015

Hi. This is very useful, but is there a way to expose the full Bayer matrix (RGGB)? This is the -D option in dcraw. Also with 16 bit enabled images each channel is split in two 8 bit images, is this intentional?

@SamWhited
Copy link
Member

I still haven't gotten around to fixing this issue, sorry. I've messed with it a bit, but the LibRaw behavior is not well defined here and doesn't appear to match the docs. I'll ask around and see if I can't get it working this weekend.

Also with 16 bit enabled images each channel is split in two 8 bit images, is this intentional?

I'll have to play with it; I'm not sure, but that's off topic for this issue.

@paalge
Copy link
Contributor

paalge commented Oct 27, 2015

No problem, I'll be glad to help if you want, as I was in the process of starting the implementation of a cpython interface with libraw when I found your module.

@SamWhited
Copy link
Member

@paalge many thanks; pull requests are always welcome.

@paalge
Copy link
Contributor

paalge commented Oct 29, 2015

I've created a pull request #104
By the way I think the reason that the 16 bit image becomes two 8 bit images is that the returned type is ushort, while bytearray assumes only one byte.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants