#63 Notes on untethered mode

None
closed
None
1
2014-04-24
2013-04-20
J Sal
No

I tested the untethered mode and was able to successfully profile a display. A couple of items of feed back:
- ideal format for the patches would be dpx. and the can be tiny. 100x100 would be fine. Maybe let us set the size?
- The auto process is surprisingly good, but goes off once in a while. I had to go back and catch it.
- Would be really helpful if we could review the reads before committing, so as to correct any misreads. I like the gui you've used, the expected and read patches are informative, but obviously do not take colorspace into consideration. However having say a scrollable window with the expected and resulting patches stacked would allow us to review all the reads and hopefully catch mistakes.
- Would also be helpful if there were two distinct audio tones, one for when a reading was being taken and the next for when a particular patch had been properly registered.
- Would it be possible to have dispcalgui automatically trigger a macro after a successful read? Picture a system with dispcalgui running in untethered mode in the background and a video io app in the foreground. When dispcalgui confirmed a read on a patch it could trigger a keyboard shortcut, or mouse click that would advance to the next patch.
-Would it be possible to have dispcalgui export a set number of repeated patches? Example, i'd like 240 frames of each actual patch, so that i could play them back at 24fps and have each patch last 10 seconds. Rather than having to manually create a sequence.

Related

Bug Reports: #63

Discussion

1 2 > >> (Page 1 of 2)
  • J Sal

    J Sal - 2013-04-20

    By the way Florian, Thanks so much for doing this. It's really worked great, and your work is appreciated.

    One related request:
    in the lut creation tool, would it be possible to allow us to set custom source colorimetry? Let us manually specify a white point / r,g,b primaries in XYZ and target gamma and then build a lut to have the display match it.

     
    • Florian Hoech

      Florian Hoech - 2013-04-20

      in the lut creation tool, would it be possible to allow us to set custom source colorimetry? Let us manually specify a white point / r,g,b primaries in XYZ and target gamma and then build a lut to have the display match it.

      I'd rather ship those pre-baked as ICC profiles (like the ones in the “ref” folder). If you tell me which ones you are missing, I can create and include them in the next release.

       
      • Anonymous - 2013-04-20

        Well it's not specific colorspaces as customization on colorspaces. And some custom stuff.

        One prebaked thing that's missing is a DCDM XYZ profile. Also an ACES profile would be handy.

         
  • Anonymous - 2013-04-20

    It's not so much missing prebaked colorspaces as custom white points and gammas we sometimes use.

    There are a couple of missing prebaked profiles though: DCDM XYZ and ACES profiles would both be handy.

     
    • Florian Hoech

      Florian Hoech - 2013-04-20

      So DCDM is different from DCI P3? Are there specifications for the DCDM colorspace available? (a quick Google search didn't turn up useful results)

       
  • J Sal

    J Sal - 2013-04-21

    DCDM XYZ is only different from DCi-P3 in as much as it uses XYZ encoding instead of RGB.

     
  • Florian Hoech

    Florian Hoech - 2013-04-22

    I see. Adding an XYZ profile is currently not possible, though.
    On another note, ACES specifies its transfer function as "relative exposure values". I'm not sure atm how this translates into gamma, if at all. So the ACES profile I have created now has unity (1.0) gamma.

     
  • J Sal

    J Sal - 2013-04-23

    Linear gamma is the correct gamma for ACES, relative exposure values are camera side dependent. As in sensors native sensitivity and intended gain. Probably not relevent in this application. Can I ask why XYZ isn't possible? Adobe is doing it with their DCI XYZ profiles. The idea wouldn't be to display XYZ but to be able to interpret them on input in RGB for monitor display.

     
  • Florian Hoech

    Florian Hoech - 2013-04-23

    ideal format for the patches would be dpx.

    That would require me rolling my own dpx writer. I'm not keen on it tbh, documentation on the exact format could also be better from what I've seen so far.

    and the can be tiny. 100x100 would be fine. Maybe let us set the size?

    Already possible (within limits). Select a not-virtual screen from the “Display” dropdown, then click one of the calibrate or profile buttons. Resize the measurement window to your liking, then close it. Exported patches will use that size.

    Would be really helpful if we could review the reads before committing, so as to correct any misreads. I like the gui you've used, the expected and read patches are informative, but obviously do not take colorspace into consideration. However having say a scrollable window with the expected and resulting patches stacked would allow us to review all the reads and hopefully catch mistakes.

    Sounds like a reasonable idea. I'll see what I can do.

    Would also be helpful if there were two distinct audio tones, one for when a reading was being taken and the next for when a particular patch had been properly registered.

    Noted, will be implemented.

    Would it be possible to have dispcalgui automatically trigger a macro after a successful read? Picture a system with dispcalgui running in untethered mode in the background and a video io app in the foreground. When dispcalgui confirmed a read on a patch it could trigger a keyboard shortcut, or mouse click that would advance to the next patch.

    That one is not easy, and probably not possible.

    Would it be possible to have dispcalgui export a set number of repeated patches? Example, i'd like 240 frames of each actual patch, so that i could play them back at 24fps and have each patch last 10 seconds. Rather than having to manually create a sequence.

    That one is easy to implement.

    Can I ask why XYZ isn't possible?

    I don't know what an XYZ profile should contain. Maybe the XYZ profiles from the ICC can be used?

     
    Last edit: Florian Hoech 2013-04-28
    • J Sal

      J Sal - 2013-04-25

      The ICC XYZ profiles don't have the correct white point or gamma unfortunately.

       
      • Florian Hoech

        Florian Hoech - 2013-04-25

        So all that needs to be changed is whitepoint and gamma? I have played around a bit and created a preliminary DCDM XYZ profile (attached). Let me know if this works.

         
        Last edit: Florian Hoech 2013-04-25
        • J Sal

          J Sal - 2013-04-25

          That's very, very close, there appears to be a slight gain from this profile... I can send you the "standard LUT" output to compare.

           
  • Florian Hoech

    Florian Hoech - 2013-04-28
    • status: open --> accepted
    • assigned_to: Florian Hoech
    • Group: -->
     
  • J Sal

    J Sal - 2013-05-03

    Exported without crash. Rather quickly!

     
    Last edit: Florian Hoech 2013-05-04
  • J Sal

    J Sal - 2013-05-03

    In the last snapshot did you by chance change the algorythym for
    autosyncing? It seems to be having a much harder time.

     
    Last edit: Florian Hoech 2013-05-04
    • Florian Hoech

      Florian Hoech - 2013-05-04

      No change to the algorythm, I just changed the measurement and commit sounds from asyncronous to syncronous playback so they play one after the other.

       
  • Florian Hoech

    Florian Hoech - 2013-05-25

    I'm preparing a new "official" release, so if there are any (preferably small ;)) changes yet required, now would be a good time to let me know.

     
  • Florian Hoech

    Florian Hoech - 2013-10-22

    I've just released dispcalGUI 1.5.2.5 which improves the reliability of untethered auto mode by allowing to optimize testcharts specifically for that mode. The result is a patch order that maximizes lightness differences from one patch to the next, thus making it easier for the automatism to detect a changing patch.

     
  • J Sal

    J Sal - 2013-10-22

    That's a great idea. Any way to have averaging of results. To profile not
    just one screen but an average for a type of screen?

    On Tue, Oct 22, 2013 at 2:37 PM, Florian Hoech fhoech@users.sf.net wrote:

    I've just released dispcalGUI 1.5.2.5 which improves the reliability of
    untethered auto mode by allowing to optimize testcharts specifically for
    that mode. The result is a patch order that maximizes lightness differences
    from one patch to the next, thus making it easier for the automatism to
    detect a changing patch.


    Status: accepted
    Created: Sat Apr 20, 2013 08:19 AM UTC by J Sal
    Last Updated: Sat May 25, 2013 02:32 PM UTC
    Owner: Florian Hoech

    I tested the untethered mode and was able to successfully profile a
    display. A couple of items of feed back:
    - ideal format for the patches would be dpx. and the can be tiny. 100x100
    would be fine. Maybe let us set the size?
    - The auto process is surprisingly good, but goes off once in a while. I
    had to go back and catch it.
    - Would be really helpful if we could review the reads before committing,
    so as to correct any misreads. I like the gui you've used, the expected and
    read patches are informative, but obviously do not take colorspace into
    consideration. However having say a scrollable window with the expected and
    resulting patches stacked would allow us to review all the reads and
    hopefully catch mistakes.
    - Would also be helpful if there were two distinct audio tones, one for
    when a reading was being taken and the next for when a particular patch had
    been properly registered.
    - Would it be possible to have dispcalgui automatically trigger a macro
    after a successful read? Picture a system with dispcalgui running in
    untethered mode in the background and a video io app in the foreground.
    When dispcalgui confirmed a read on a patch it could trigger a keyboard
    shortcut, or mouse click that would advance to the next patch.
    -Would it be possible to have dispcalgui export a set number of repeated
    patches? Example, i'd like 240 frames of each actual patch, so that i could
    play them back at 24fps and have each patch last 10 seconds. Rather than
    having to manually create a sequence.


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/dispcalgui/bug-reports/63/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Bug Reports: #63

    • Florian Hoech

      Florian Hoech - 2013-10-22

      There's currently no UI for the averaging part, but it is already possible. You can use dispcalGUI for the measurements. Instead of clicking "profile only", choose "measure testchart" from the options menu. Once you have acquired all the measured files you want to use for the averaging, you need a brief excursion to the commandline, using the Argyll CMS tools. Like so:

      average first.ti3 second.ti3 third.ti3 (and so on...) averaged.ti3
      

      Then, choose your profiling parameters in dispcalGUI, select "create profile from measurement data" from the options menu and select your averaged.ti3. Voila. I might add some UI for it in a future version.

       
  • Florian Hoech

    Florian Hoech - 2013-10-23

    I've just pushed an update that fixes two bugs and introduces the ability to average measurement files. So instead of using the commandline above, you can just select multiple files and they will be averaged together.

     
1 2 > >> (Page 1 of 2)


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks