Getting single color channels histogram values not working?

as documented here
but seems not to be working for single color channels
for RGB histogram works though.
What am i missing?

Channel has to be visible to make it work (or selected I am not sure… but probably visible). I consider this as a bug. I would like to see that fixed.

Hi Jarda, thanks for helping.
Yep, checked the documents and channels are visible but no luck with fetching the data.

Seems broken to me, too:

BatchPlay works fine though:

      _obj: "get",
      _target: [
            _property: "histogram"
            _enum: "channel",
            _ref: "channel",
            _value: "red"
      _options: {
         dialogOptions: "dontDisplay"
],{synchronousExecution: true})[0].histogram;

Thank you Simon. Will use that as workaround.
BTW did anyone measure DOM vs Batchplay execution time? I remember DOM was slow in CEP sometimes.

The DOM will always be slower than calling batchPlay directly, as it has a lot of guard logic to (try to) avoid bad states, and has to convert internal data structures into more JS-friendly data types. (Side note: the DOM is built over batchPlay w/ additional wrapping logic.)

One advantage over CEP, though, is that there’s no evalScript bridge you have to go through to call the DOM. So there are some speed/context advantages there, but these benefits hold true for the following:

If you want speed*, batchPlay is the closest to the Ps metal you can get.

And you should take advantage of the word batch in the name – if you batch up a lot of actions and send them over in one go, it’ll be faster than waiting on them all individually. (This assumes you don’t need to have any logic between steps, of course, so you probably won’t be able to batch everything together.)

* I use “speed” here very loosely. I mean this as in, as fast as Ps can execute it. batchPlay and the DOM are limited to the underlying Ps performance – if a Ps action is slow, neither batchPlay nor the DOM can be any faster.

@Michel77 Are you in the Ps prerelease? If so, it’d be good to file a bug on the DOM error you’re seeing.

I just did a little test: Duplicating the active layer and scaling it by 100.2% X times.

10 Repetitions:

  • BatchPlay (1 call with 20 Descriptors)
    Time to execute script: 363 ms
  • BatchPlay (10 calls with 2 Descriptors each)
    Time to execute script: 460 ms
  • DOM
    Time to execute script: 962 ms

So there’s already a large performance loss in using DOM. One thing I noticed is that for some reason the DOM does something weird: Once it’s done with the script it has X layer reordering steps in the history, where it puts the last layer back to the index above the first layer and then step by step back to the index where it’s supposed to be (last/top position). So if you use DOM, you also expose yourself to such bugs. @kerrishotts Would be nice to get some insight into what’s happening under the hood. Or is my for-each loop in any way causing the issue?:

iterable(10).forEach(() => {
  doc.activeLayers[0].scale(100.2, 100.2)

This reordering of layers can take super long and leaves Photoshop in an unresponsive state.

100 Repetitions:

  • BatchPlay (1 call with 200 Descriptors)
    Time to execute script: 3705 ms
    Time for UI to be responsive: not noticable
  • BatchPlay (100 calls with 2 Descriptors each)
    Time to execute script: 5244 ms
    Time for UI to be responsive: not noticable
  • DOM
    Time to execute script: 10412 ms
    Time for UI to be responsive: 15 seconds

1000 Repetitions:

  • BatchPlay (1 call with 2000 Descriptors)
    Time to execute script: 66648 ms
    Time for UI to be responsive: not noticable
  • BatchPlay (1000 calls with 2 Descriptors each)
    Time to execute script: 78008 ms
    Time for UI to be responsive: not noticable
  • DOM
    Time to execute script: 156715 ms
    Time for UI to be responsive: 12 minutes !

So using batchPlay with as many Descriptors grouped in one call as possible will give you the fastest results.

Btw, I recently noticed that suspending history or not may also effect the performance slightly, or at least the visible “render steps” the user sees (while the script is running).

1 Like

Years ago, I had some fun creating a DOM script running super fast using the histogram data array of the three channels and the luminosity histogram. I used that data to re-create four colored vectorized layers that redraw my histogram over a group of 4 layers.
I used only DOM then. I remember the use of paths, subpaths, anchor points, etc. Using dom was superfast.
I also remember using a way slower solution on a first attempt to create 256 vectorized columns (rectangles) :slight_smile: It was too slow, like 14 seconds.
So I used 4 single paths with 514 anchor points each (one for each channel), filled with color, and it ran way faster, like 2 seconds.

Here is the DOM
var hL = activeDocument.histogram;
var hR = activeDocument.channels[“Red”].histogram;
var hG = activeDocument.channels[“Green”].histogram;
var hB = activeDocument.channels[“Blue”].histogram;