Loading ...
Sorry, an error occurred while loading the content.

ProPhoto RGB Color Space - do the tools & front ends support it?

Expand Messages
  • LoveFilm
    Does PTgui s native algorithms support a work flow where the images are in the ProPhoto RGB Color space? And what about PTstitcher, PTmender, Enblend, and
    Message 1 of 8 , Aug 1, 2006
    • 0 Attachment
      Does PTgui's native algorithms support a work flow where the images
      are in the ProPhoto RGB Color space?

      And what about PTstitcher, PTmender, Enblend, and Samrtblend - can
      they support a ProPhoto RGB work flow?

      I process and store all my work in this huge color space, -
      converting to other formats as my needs dictate. I haven't tried it
      for panoramas yet but would like to now start bringing my pano source
      materials in line with the rest of the way I work.

      Pete.
    • Mr. Roger Howard
      ... All the tools you mention are essentially color management-ignorant, so the short answer is yes . None of these tools will do any color space conversion,
      Message 2 of 8 , Aug 1, 2006
      • 0 Attachment
        On Aug 1, 2006, at 6:01 PM, LoveFilm wrote:

        >
        > Does PTgui's native algorithms support a work flow where the images
        > are in the ProPhoto RGB Color space?
        >
        > And what about PTstitcher, PTmender, Enblend, and Samrtblend - can
        > they support a ProPhoto RGB work flow?
        >
        > I process and store all my work in this huge color space, -
        > converting to other formats as my needs dictate. I haven't tried it
        > for panoramas yet but would like to now start bringing my pano source
        > materials in line with the rest of the way I work.

        All the tools you mention are essentially color management-ignorant,
        so the short answer is "yes". None of these tools will do any color
        space conversion, so the colors you feed in come out untouched. The
        catch is that most tools do not copy the source document's ICC
        profile into the output, so your output files are untagged (but,
        crucially, still in the same color space). PTGUI I believe is
        properly bringing source profiles over now. In any case, you can work
        in any RGB space you want, but you'll likely need to retag the output
        with the same space as your input.

        In other words, ProPhotoRGB is supported as well as any other RGB space.

        Now, whether ProPhotoRGB is useful is another question for another
        thread :) I will say, if you're working in ProPhotoRGB it's far more
        important to use a full 16bit workflow than in smaller spaces, since
        ProPhotoRGB is more susceptible to banding from edits than smaller
        spaces.. but this is OT :)

        -R
      • LoveFilm
        I just realized there might be no benefit to inputting ProPhoto RGB images into the panoramic chain - since I don t really do any editing to the source
        Message 3 of 8 , Aug 1, 2006
        • 0 Attachment
          I just realized there might be no benefit to inputting ProPhoto RGB
          images into the panoramic chain - since I don't really do any editing
          to the source materials till after they are stitched (in which case I
          could always converted to that color space if necessary).

          Or would the larger color space - if supported - provide some benefit
          to guard against things like banding in the sky, as working in 16bit
          does ???


          --- In PanoToolsNG@yahoogroups.com, "LoveFilm" <lovefilm@...> wrote:
          >
          >
          > Does PTgui's native algorithms support a work flow where the images
          > are in the ProPhoto RGB Color space?
          >
          > And what about PTstitcher, PTmender, Enblend, and Samrtblend - can
          > they support a ProPhoto RGB work flow?
          >
          > I process and store all my work in this huge color space, -
          > converting to other formats as my needs dictate. I haven't tried it
          > for panoramas yet but would like to now start bringing my pano source
          > materials in line with the rest of the way I work.
          >
          > Pete.
          >
        • LoveFilm
          Wow...and here I was thinking ProPhoto might help guard AGAINST banding! But I always wortk in 16bit anyway. Still.. good info to know. Thanks!
          Message 4 of 8 , Aug 1, 2006
          • 0 Attachment
            Wow...and here I was thinking ProPhoto might help guard AGAINST
            banding! But I always wortk in 16bit anyway. Still.. good info to
            know. Thanks!

            > Now, whether ProPhotoRGB is useful is another question for another
            > thread :) I will say, if you're working in ProPhotoRGB it's far more
            > important to use a full 16bit workflow than in smaller spaces, since
            > ProPhotoRGB is more susceptible to banding from edits than smaller
            > spaces.. but this is OT :)
            >
            > -R
            >
          • Mr. Roger Howard
            ... Why are you picking ProPhoto to begin with? Have you done any testing that shows you a benefit of working in this space? In any case... let s assume you ve
            Message 5 of 8 , Aug 1, 2006
            • 0 Attachment
              On Aug 1, 2006, at 6:12 PM, LoveFilm wrote:

              > I just realized there might be no benefit to inputting ProPhoto RGB
              > images into the panoramic chain - since I don't really do any editing
              > to the source materials till after they are stitched (in which case I
              > could always converted to that color space if necessary).

              Why are you picking ProPhoto to begin with? Have you done any testing
              that shows you a benefit of working in this space? In any case...
              let's assume you've selected ProPhoto for a reason. Then it would
              make *no* sense to use a smaller gamut space first, and then convert
              to ProPhoto. ProPhoto, if you have a reason to use it, should always
              be used before smaller gamut spaces in your process, not after, or
              it's lost any value it might have.

              > Or would the larger color space - if supported - provide some benefit
              > to guard against things like banding in the sky, as working in 16bit
              > does ???

              Actually quite the opposite. The simplest explanation is this:

              In digital images the tonal scale, from white to black, is cut up
              into a fixed number of tones. In a wider gamut space, that number of
              tones has to cover a *wider* range than in a smaller space, therefore
              the steps in between each tone are larger, and any loss of tones
              because of compression/expansion will be more obvious. Therefore
              larger gamut spaces tend to show banding sooner.

              In fact the ongoing, multi-year debate on a few other mailing lists
              about 8 vs 16 bits has only been able to really agree on a single
              point - that 16bit CAN be useful when working in wide gamut spaces
              like ProPhoto. So at least if you're going to use ProPhoto, you
              should use 16bit.

              But my advice is to work in sRGB until you understand all of this, or
              at most work in Adobe RGB. Test as much as possible and see if you
              can find any real situation where the wider gamut space makes any
              difference in the quality of your work - I'll bet it won't, or it may
              actually have a negative impact.

              -R
            • LoveFilm
              ... testing that shows you a benefit of working in this space? I have been using ProPhoto for a little over a year now - Mostly for my Product Shots, since
              Message 6 of 8 , Aug 1, 2006
              • 0 Attachment
                --- In PanoToolsNG@yahoogroups.com, "Mr. Roger Howard"
                <rogerhoward@...> wrote:
                >
                >
                > Why are you picking ProPhoto to begin with? Have you done any
                testing that shows you a benefit of working in this space?

                I have been using ProPhoto for a little over a year now - Mostly for
                my Product Shots, since these images are frequently being used for
                mult-purposes, such as on the web and for print. It is my
                understanding that ProPhoto is an excellent 'storage' color space,
                from which one file can then easily be converted to other spaces
                according to indented output.

                Until just now, I hadn't really considered it for pano creation and I
                guess the only benefit would be to maintain a consistent work flow
                with all my other photos.


                if you have a reason to use it, should always
                > be used before smaller gamut spaces in your process, not after, or
                > it's lost any value it might have.

                Thanks, you confirmed what I initiallly suspected.


                >
                > In fact the ongoing, multi-year debate on a few other mailing lists
                > about 8 vs 16 bits has only been able to really agree on a single
                > point - that 16bit CAN be useful when working in wide gamut spaces
                > like ProPhoto. So at least if you're going to use ProPhoto, you
                > should use 16bit.

                I do always use it w/ 16 bit. Regarding some of the other forums,
                here is a current thread on Kekus regarding 'color degration' that
                might be of interest.

                http://www.kekus.com/forum/showthread.php?t=1429
              • JD Smith
                ... Hugin v0.6 also copies input ICC profiles to the output.
                Message 7 of 8 , Aug 2, 2006
                • 0 Attachment
                  On Tue, 01 Aug 2006 18:11:21 -0700, Mr. Roger Howard wrote:

                  > All the tools you mention are essentially color management-ignorant, so
                  > the short answer is "yes". None of these tools will do any color space
                  > conversion, so the colors you feed in come out untouched. The catch is
                  > that most tools do not copy the source document's ICC profile into the
                  > output, so your output files are untagged (but, crucially, still in the
                  > same color space). PTGUI I believe is properly bringing source profiles
                  > over now. In any case, you can work in any RGB space you want, but you'll
                  > likely need to retag the output with the same space as your input.

                  Hugin v0.6 also copies input ICC profiles to the output.
                • Roger Howard
                  ... Yay! Now how about copying EXIF/XMP/IPTC? You could integrate ExifTool from Phil Harvey for this. Or even better, how about a standard way to run a
                  Message 8 of 8 , Aug 2, 2006
                  • 0 Attachment
                    On Wed, August 2, 2006 9:23 am, JD Smith wrote:
                    > On Tue, 01 Aug 2006 18:11:21 -0700, Mr. Roger Howard wrote:
                    >
                    >> All the tools you mention are essentially color management-ignorant, so
                    >> the short answer is "yes". None of these tools will do any color space
                    >> conversion, so the colors you feed in come out untouched. The catch is
                    >> that most tools do not copy the source document's ICC profile into the
                    >> output, so your output files are untagged (but, crucially, still in the
                    >> same color space). PTGUI I believe is properly bringing source profiles
                    >> over now. In any case, you can work in any RGB space you want, but
                    >> you'll
                    >> likely need to retag the output with the same space as your input.
                    >
                    > Hugin v0.6 also copies input ICC profiles to the output.

                    Yay!

                    Now how about copying EXIF/XMP/IPTC? You could integrate ExifTool from
                    Phil Harvey for this.

                    Or even better, how about a standard way to run a post-render script so I
                    can do it myself if needed? This way we could attach a script to each
                    render process that will get fired off at the end, ideally with the paths
                    to source and output images (or just the whole PTO script) passed to the
                    post-script.

                    I do this with a hotfolder now, but it's a bit tricky to get timing right
                    in all cases. I'd rather do it explicitly this way than have a script have
                    to poll for the status of an output files file locks.

                    -R
                  Your message has been successfully submitted and would be delivered to recipients shortly.