Lord metroid
Forum Enthusiast
- Messages
- 476
- Reaction score
- 117
Then it imperative that we fist and foremost back engineer RAW to RGB and create a library to handle that.
-
Welcome to the new forums! Please read this first. For known issues we are working to resolve, click here.
X3 Developer - calling all software minds..
- Thread starter amilewide
- Start date
Roland Karlsson
Forum Pro
That is one way of saying it
I have a pretty fair amount of experience with GPUImage, having used it in two commercial apps for iOS. It has a 4k x 4k size limit for its textures ingrained in the code, a problem that Brad Larson has acknowledged but probably won't fix until an Apple camera has a resolution that requires increasing that limit.
I tried to do some stress testing of the apps with Merrill files, and it didn't work so well for that very reason.
I tried to do some stress testing of the apps with Merrill files, and it didn't work so well for that very reason.
Kendall Helmstetter Gelner
Forum Pro
The "market share" of PC systems sold includes company computers that sit on desks and do something simple.
Much more telling is that Apple has something like 80% of the high-end laptop market share now...
Go to a photography conference and the estimate for Mac use by photographers is way north of 50%, not anything like 25%.
Don't think that's the issue.
MarkWW
Leading Member
With the word "just" added in a couple of places, it would have been perfect ;-)That is one way of saying it
--
Cheers,
Ted
Last edited:
I wouldn't bother because I went to their site and, unlike other sites, nowhere is there a list of supported formats, unless I missed it. Apparently you have download their stuff, then try it with a file and, if nothing happens, the format is not supported.
I'm trying Qimage which does open X3Fs (at least SD9 thru SD14 and DP1) but it's main purpose seems to be for batch printing and I don't print. I find the user interface a little odd but it appears to work and has a good few tools.
I'm still trying to gauge whether this thread wants a bare-bones converter (raw to TIFF) or a full-blown equivalent of PhotoShop?
Roland Karlsson
Forum Pro
Several matrices, actually, Mark. The most significant perhaps being the one that transforms camera raw values into CIE XYZ co-ordinates.
As a bonus for pre-Merrill users and maybe pre-AFE users I offer a bare-bones toy where a cam to RGB matrix is actually adjustable!
Loading…
kronometric.org
Unzipping gives three folders: Linux, OSX, Windows versions.
Couldn't find it on CEZEO's site so it's up on mine for a limited time.
For my camera models (and according to ArvoJ) the cam-to-XYZ matrix is different for each sensor so as to match the variable space per sensor to the WB matrices, etc. That is each individual sensor, not sensor or camera model. So, if that is true for all Sigma camera models, would you be using that matrix as part of your RGB extractor?
The CEZEO reader apparently does not and, with default matrix co-efficients set, can be dark (no auto-brightening) and is a bit heavy on purples (i.e. red and blue content). It does do the same or similar to your raw extractor if you alter the CEZEO matrix to a 1,1,1 diagonal.
Why does it have a 4K x 4K limit? Is it a speed issue? Can't that be doubled easily? I'm thinking that if it's a program designed for manipulating images it needs to be modified ASAP, because even some of the cameras in cell phones out there now make photos that are more than 3,780 pixels on the longest side - some are more than 5,000 pixels on the longest side. Doubling the dimensions would make the program work for every popular digital camera for years to come (even for Quattro files exported from SPP at S-HI size). If it's a speed issue, I would think it might make sense to give the program a "hi-res" mode, which can be switched on and off, so people CAN use larger images with it, but more slowly. Have you tried to play with the code, to increase the size of images it can handle?
It's a GL version issue. See here:
Loading…
stackoverflow.com
Loading…
stackoverflow.com
Basically, the GPU is intended to draw things to the screen. The fact that it can be used to process larger images (or other things, like physics simulation) is a happy accident, but not the main purpose of the subsystem. Brad's library is mainly about capturing video and stills from the iPhone and mac cameras, and then manipulating those stills. As Apple has yet to release a camera larger than 4k x 4k, there's no pressing need to increase the texture size, or to implement tiling (ie, stitching together smaller textures and having some code to handle the border cases).
Kendall Helmstetter Gelner
Forum Pro
Well, RawDigger uses LibRaw and supports all Sigma cameras up to and including Merrill, so that's the bare-bones bit right there, eh? But Iliah and Alex seem to have missed this thread - or maybe there's a Great Silence happening there . .
CoreImage != GPUImage. He may decide to start doing that under the hood, but last I checked, it was all pretty much straight up OpenGL ES.
Can you point me to a link about automatic tiling? Because I've always had to be very careful about edge conditions when doing tiling if doing any kind of nontrivial filtering involving more than just the current pixel, I'd be cautious about how they're doing this.
Can you point me to a link about automatic tiling? Because I've always had to be very careful about edge conditions when doing tiling if doing any kind of nontrivial filtering involving more than just the current pixel, I'd be cautious about how they're doing this.
Kendall Helmstetter Gelner
Forum Pro
I know, I'm just saying that at least a foundation exists that does do tiling that something could be written on top of.
I don't think they've produced anything with much technical detail yet, all I know is a summary of what is possible from watching a WWDC 2014 video on "what is new in Core Image" (which also talks about custom CoreImage filters for the RAW image pipeline).
Apple in general though has a ton of image processing expertise, so I'm pretty sure they are doing a careful job of this.
So Kendall, how much do you know about GPU image processing accelleration? With a raw image processor capable of using the GPU, would it make sense to get a slower computer for $200 less and add a second identical video card for $150, saving money and increasing image processing power, or does having multiple video cards not matter, when using GPU-based image processing?
Ted, from what you said about LibRaw, I'm inclined to believe that "engine" is probably superior to DCraw becuase of this. What do YOU think?
Ted, from what you said about LibRaw, I'm inclined to believe that "engine" is probably superior to DCraw becuase of this. What do YOU think?
Kendall Helmstetter Gelner
Forum Pro
It depends on the application, for some applications another video card does add more processing power. If it's just doing simpler calculations on the GPU the system would just use the fastest one.
Neither would help SPP at the moment though. I think in general you are always well off getting near to the top (but not quite top) of the line CPU, and a fairly powerful GPU if possible to help future-proof your purchase as much as you can.
It seems like it would be a better choice for a RAW conversion library if you were building a new app.
Roland Karlsson
Forum Pro
Search for "gpu jpeg compression" on google.
It seems to be a rather popular topic.
It seems to be a rather popular topic.
victorgv
Senior Member
- Messages
- 2,295
- Solutions
- 1
- Reaction score
- 1,569
Similar threads
Keyboard shortcuts
- f
- Forum