Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Image Data Access

JSS

Here are three features C1 does not have and could be supplied by the developer community IF C1 had the proper interface: (1) a raw level HDR merge, (2) focus stack merge, and (3) pixel-shift merge.  Currently, C1 users have to process all the way to TIFF to do these, or worse, use other software to perform the merge from raw to TIFF thus forgoing the powerful C1 raw rendering capabilities.

You will note previous forum posts where developers have wanted to develop such a plugin (pixel-shift merge), but have been frustrated but the lack of the proper API.

As I understand it, the API will provide access to original RAW files - which doesn't help much as 3rd party developers won't have access to proprietary RAW format information, or the resources to develop for, such a wide range of files.

We need access to linearized RAW data; specifically, linearization, black subtraction, rescaling, and clipping, as described in Chapter 5 of the DNG standard.  The plug-in could import this linearized raw data format, and then return data in the same format where the C1 processing chain takes over.

A 16-bit DNG file interface would be sufficient for pixel-shift and focus stack merge, but not for an HDR merge.  For HDR, we'd want a 32-bit format like the HDR-DNG files that Lightroom produces.  The last time I tried, C1 did not recognize these HDR-DNG files (although it does support the 16-bit linearized raw DNG).  One would think that with 16-bit PhaseOne cameras, C1 would be developing some 32-bit processing capability.  Why not define a C1 interface based on 32 bit IEEE floating point?

4

Comments

5 comments

Date Votes
  • Sean Baker

    Strongly recommend / request the ability to do this. Frankly this could largely replace PS for a lot of folks if successful.

    In order of increment / implementation:

    1. Simple plugins which are given TIFF-style access to the image data and allowed a UI.
    2. Layer-based plugins which are given TIFF-style access to the underlying image data, are masked by the layer configuration, and return TIFF-style data for the next layer. NOTE: C1 should process the return as a 32bit delta from the original as a way to preserve subsequent processing quality.
    3. Iteration on the above to allow plugins to specify the format in which they seek to receive input. I.e. TIFF / DNG / RAW matrix, as well colorspace and bit depth. This can obviously be itself iterated.
    4. Allow plugins to call other C1 capabilities or possibly each other (more below).
    5. Allow plugins to define masks, preferably dynamically.

    Why do this?

    1. #1 above would allow in-session color profiling from ColorCheckers, etc. Best if coupled with dynamic loading of color profiles from the OS, but still VASTLY better than the current process.
    2. #2 above gets you everything which the OP mentioned, as well (and most importantly), everything else which no one has considered here. (#3 then improves the quality substantively).
    3. What if we could have an AI plugin which would auto-heal images of detected faces? Talk about a workflow pipeline! We're not far from having the same ability for cleaning up hair, etc. Why go to PS anymore at all?
    4. Direct competition for photo processing ala PhotoShop. Compatibility with PS plugins would also be neat but may not be worth the potential legal issues ala Google / Oracle.

    All pie in the sky, but would be super helpful.

    2
  • Fixel Algorithms

    Have anyone seen response from Capture One on this forum?

    0
  • Luis Muñoz

    Good point.
    I certainly don't.
    I definitely think C1 should look after the health and dynamics of this forum.

    0
  • Sawayn Emery

    This function uses the AnalysexVPAT functions to verify if the image can support direct linear access to the data PayGOnline. If the function returns TRUE, it is possible to access the image data via a pointer.

    -1
  • Peter Graf

    I most strongly second this.

    I am in dire need of DNG 1.4 16-Bit float to deal with HDR images coming from a Ricoh Theta Z1 Dual Fisheye Plugin.

    I can also create stitched 360 Panorama Images in PTGui from sources like that, but I cannot maintain the high data levels (including OpenEXR, HDR Radiance or 32-Bit TIFF) required to transfer optimal source for further processing in C1.

    Requirements for HDR processing are only going to get more in the future. Please dedicate some coding power to this. Thanks for listening @CaptureOnePro 

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post