"Info" broken in CS?

Check the area being sampled by the eyedropper tool…
Other than that, I can’t reproduce what you’re seeing.

Chris

In article
wrote:

I’m finding that the info tool is not giving the correct answers in CS. Also, it is very slow at updating, sometime freezing its numbers for seconds at a time when I move the cursor.

I used a program (BOB) to dump RAW canon 10D files without interpolation; i.e., each pixel was 0 in two of the three RGB channels. If I load the image into photoshop, at any low level of zoom, only the green channel has anything besides 0 in it, no matter where I put the cursor (sort of expected at some zoom levels), but when I go to 100% or above, I get values for green that are higher than the red, even if there is no green in the pixel (saturated red).

Is the Info tool buggy for everyone, or am I crazy?

In message <281120032209173035%>,
Chris Cox wrote:

Check the area being sampled by the eyedropper tool…
Other than that, I can’t reproduce what you’re seeing.

The eyedropper yields the same results – nonsense RGB values. A bright red pixel without a hint of green or blue in it might read:

R 170
G 216
B 200

And, as I said earlier, the update is extremely slow. The RGB info will stay frozen for up to 3 seconds after I move it to a new pixel. The whole GUI feels extremely sluggish compared to 7.01, and mouse events are routinely ignored, or the wrong tool shows under the cursor for a few seconds after placing it over a window.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

In article , wrote:

In message <281120032209173035%>,
Chris Cox wrote:

Check the area being sampled by the eyedropper tool…
Other than that, I can’t reproduce what you’re seeing.

The eyedropper yields the same results – nonsense RGB values. A bright red pixel without a hint of green or blue in it might read:
R 170
G 216
B 200

And, as I said earlier, the update is extremely slow. The RGB info will stay frozen for up to 3 seconds after I move it to a new pixel. The whole GUI feels extremely sluggish compared to 7.01, and mouse events are routinely ignored, or the wrong tool shows under the cursor for a few seconds after placing it over a window.

John, my bet is that you have some other program interfering. What else are you running at the same time?

In message ,
(jjs) wrote:

In article , wrote:

In message <281120032209173035%>,
Chris Cox wrote:

Check the area being sampled by the eyedropper tool…
Other than that, I can’t reproduce what you’re seeing.

The eyedropper yields the same results – nonsense RGB values. A bright red pixel without a hint of green or blue in it might read:
R 170
G 216
B 200

And, as I said earlier, the update is extremely slow. The RGB info will stay frozen for up to 3 seconds after I move it to a new pixel. The whole GUI feels extremely sluggish compared to 7.01, and mouse events are routinely ignored, or the wrong tool shows under the cursor for a few seconds after placing it over a window.

John, my bet is that you have some other program interfering. What else are you running at the same time?

It turned out to be another program interfering, as far as the slow update is concerned. After a fresh reboot and running only PS CS, though, I still get bogus RGB values (CMYK and HSB are bogus, also, BTW).

Can anyone else try this:

1) Open a new canvas, 400×400 8bit, 128,128,128 grey

128,128,128 everywhere, according to Info

2) Add noise 10%

lots of accurate numbers in the vicinity of 128

3) Equalize

now, lots of dark, almost black pixels are showing "bright" RGB values, and color values do not match actual hues.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

In message ,
wrote:

In message <281120032209173035%>,
Chris Cox wrote:

Check the area being sampled by the eyedropper tool…
Other than that, I can’t reproduce what you’re seeing.

The eyedropper yields the same results – nonsense RGB values. A bright red pixel without a hint of green or blue in it might read:
R 170
G 216
B 200

And, as I said earlier, the update is extremely slow. The RGB info will stay frozen for up to 3 seconds after I move it to a new pixel. The whole GUI feels extremely sluggish compared to 7.01, and mouse events are routinely ignored, or the wrong tool shows under the cursor for a few seconds after placing it over a window.

Oh, yeah, this is the Windows version running under XP.

The sluggishness went away when I closed all the other programs. This is the first time in a very long time that I have ever had an app not respond because of what another app was doing. If it happens again, I’ll have to check the priorities of the programs.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

in article at
wrote on 11/29/03 11:04 AM:

In message ,
wrote:

In message <281120032209173035%>,
Chris Cox wrote:

Check the area being sampled by the eyedropper tool…
Other than that, I can’t reproduce what you’re seeing.

The eyedropper yields the same results – nonsense RGB values. A bright red pixel without a hint of green or blue in it might read:
R 170
G 216
B 200

And, as I said earlier, the update is extremely slow. The RGB info will stay frozen for up to 3 seconds after I move it to a new pixel. The whole GUI feels extremely sluggish compared to 7.01, and mouse events are routinely ignored, or the wrong tool shows under the cursor for a few seconds after placing it over a window.

Oh, yeah, this is the Windows version running under XP.

The sluggishness went away when I closed all the other programs. This is the first time in a very long time that I have ever had an app not respond because of what another app was doing. If it happens again, I’ll have to check the priorities of the programs.

—-
You don’t have Norton running in the background – do you?

MSD

wrote:

It turned out to be another program interfering, as far as the slow update is concerned.

What other program?

—
Regards
Madsen.

In message ,
Thomas Madsen wrote:

wrote:

It turned out to be another program interfering, as far as the slow update is concerned.

What other program?

I don’t remember all of them, but one was Bob, the Canon converter. I use Bob because it can output RAW data in a PSD file, without any processing.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

In message <BBEE509D.FB35%>,
WharfRat wrote:

in article at
wrote on 11/29/03 11:04 AM:

The sluggishness went away when I closed all the other programs. This is the first time in a very long time that I have ever had an app not respond because of what another app was doing. If it happens again, I’ll have to check the priorities of the programs.

You don’t have Norton running in the background – do you?

No Norton on that machine.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

wrote: wrote:

I don’t remember all of them, but one was Bob, the Canon converter. I use Bob because it can output RAW data in a PSD file, without any processing.

Ok. Thanks. I was just curious because I’m experiencing a sluggish info palette too. Especially when I’m in 16-bit RGB mode. (I’m not using the Canon converter though).

—
Regards
Madsen.

In message ,
wrote:

Is the Info tool buggy for everyone, or am I crazy?

I just figured out what was wrong with info. The color sampler and eyedropper tools have a common setting of single point, or 3×3 or 5×5. The default was 5×5, and this affected the info even when other tools were selected.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

wrote:

The default was 5×5, and this affected the info even when other tools were selected

The default setting for the eyedropper and color sampler tool is ‘Point Sample’.

—
Regards
Madsen.

In message ,
Thomas Madsen wrote:

wrote:

The default was 5×5, and this affected the info even when other tools were selected

The default setting for the eyedropper and color sampler tool is ‘Point Sample’.

Very interesting, as I have never changed it from the installion 3 weeks ago.

Now my next mystery; why the numbers created by Bob are not consistent. I have all interpolation and all black point compensation turned off, but it is giving me noise on top of the noise. The first level above 0 should be about 65 to 70 in 16-bit 2.2-gamma space, yet I get figures like 59, 65, 68, etc. It’s almost as if the shadows are being dithered by Bob. A 1 coming out of the 12 bit linear space should be about a single number about 70, a 2 about 130, a 3 about 180, etc. There could not possibly be any in-between numbers coming from the RAW data; Bob itself must be dithering the numbers for 16-bit space.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

John, you might want to go back to the BOB Workspace on GotDotNET and let them know about the problems you are encountering. They are using Dave Coffin’s DCRAW converter as a base for their program. If you have ever used the command line version of Dave’s program, it does the same thing. So, it could be the source of the problem. Most images initally converted with it come out fairly dark, until you set some of the settings higher than what the Help suggests. I wrote a VB.NET program that shelled to DCRAW and passed the command line arguments to it, same results, dark images.(which cleaned up fine in Photoshop)
Supposedly, the converter in the Adobe Camera RAW Plugin and the built-in version in PS CS, are also based on DCRAW. I just think that Adobe’s programmers refined the code and fixed the problem in their version. james

wrote in message

In message ,
Thomas Madsen wrote:

wrote:

The default was 5×5, and this affected the info even when other tools were selected

The default setting for the eyedropper and color sampler tool is ‘Point Sample’.

Very interesting, as I have never changed it from the installion 3 weeks ago.

Now my next mystery; why the numbers created by Bob are not consistent. I have all interpolation and all black point compensation turned off, but it is giving me noise on top of the noise. The first level above 0 should be about 65 to 70 in 16-bit 2.2-gamma space, yet I get figures like 59, 65, 68, etc. It’s almost as if the shadows are being dithered by Bob. A 1 coming out of the 12 bit linear space should be about a single number about 70, a 2 about 130, a 3 about 180, etc. There could not possibly be any in-between numbers coming from the RAW data; Bob itself must be dithering the numbers for 16-bit space.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

In article
wrote:

In message ,
wrote:

Is the Info tool buggy for everyone, or am I crazy?

I just figured out what was wrong with info. The color sampler and eyedropper tools have a common setting of single point, or 3×3 or 5×5. The default was 5×5, and this affected the info even when other tools were selected.

That’s why I said to check the eyedropper options…

Chris

In article <bgpyb.31899$>,
james wrote:

Supposedly, the converter in the Adobe Camera RAW Plugin and the built-in version in PS CS, are also based on DCRAW. I just think that Adobe’s programmers refined the code and fixed the problem in their version. james

No – the Adobe Camera RAW code is developed 100% by Adobe.

Chris

Chris, check this link: http://www.cybercom.net/~dcoffin/resume.html It is Dave’s Resume’ and in it he states that his converter is used by several major commercial image programs including"Photoshop". As I said, Adobe’s Camera RAW converter is "based" on DCRAW and most likely refined by Adobe’s programmers.
james

"Chris Cox" wrote in message

In article <bgpyb.31899$>,
james wrote:

Supposedly, the converter in the Adobe Camera RAW Plugin and the

built-in

version in PS CS, are also based on DCRAW. I just think that Adobe’s programmers refined the code and fixed the problem in their version. james

No – the Adobe Camera RAW code is developed 100% by Adobe.
Chris

"james" wrote in
news:uNxyb.32503$:

Chris, check this link: http://www.cybercom.net/~dcoffin/resume.html It is Dave’s Resume’ and in it he states that his converter is used by several major commercial image programs including"Photoshop". As I said, Adobe’s Camera RAW converter is "based" on DCRAW and most likely refined by Adobe’s programmers.

Check the credits screen in Photoshop for "Chris Cox".

It should be interesting to see his reply to this.

Yes, I know Chris works for Adobe. And it should be interesting. I would think that Dave would not make that claim unless it had some validity. james

"Eric Gill" wrote in message

"james" wrote in
news:uNxyb.32503$:

Chris, check this link: http://www.cybercom.net/~dcoffin/resume.html It is Dave’s Resume’ and in it he states that his converter is used by several major commercial image programs including"Photoshop". As I said, Adobe’s Camera RAW converter is "based" on DCRAW and most likely refined by Adobe’s programmers.

Check the credits screen in Photoshop for "Chris Cox".
It should be interesting to see his reply to this.

"james" wrote in
news:g1Ayb.29206$:

"Eric Gill" wrote in message

"james" wrote in
news:uNxyb.32503$:

Chris, check this link: http://www.cybercom.net/~dcoffin/resume.html It is Dave’s Resume’ and in it he states that his converter is used by several major commercial image programs including"Photoshop". As I said, Adobe’s Camera RAW converter is "based" on DCRAW and most likely refined by Adobe’s programmers.

Check the credits screen in Photoshop for "Chris Cox".
It should be interesting to see his reply to this.

Yes, I know Chris works for Adobe. And it should be interesting. I would think that Dave would not make that claim unless it had some validity.

I would like to think that no one makes a claim unless that claim has some validity; however, the usenet will quickly disabuse one of that over- optimism.

In article <uNxyb.32503$>,
james wrote:

Chris, check this link: http://www.cybercom.net/~dcoffin/resume.html It is Dave’s Resume’ and in it he states that his converter is used by several major commercial image programs including"Photoshop". As I said, Adobe’s Camera RAW converter is "based" on DCRAW and most likely refined by Adobe’s programmers.

I’m pretty sure that Photoshop’s code is not based on DCRAW (especially since I’ve seen our code go through several major revisions). Also, he claims to have his code used in other products that I know were developed quite independently.

About all we got from outside sources was details on a few of the undocumented tags (but most we had to decipher ourselves).

Chris

Ok Chris, I guess that Dave is just making a false claim that other raw decoders are based on his work.
Of course there is no way to really know is there? Adobe nor any of the other software developers that he mentions would not offer their version of raw conversion code for inspection, much less, give Dave credit for inspiration. Especially since his code has been publicly available for quite some time.
Thanks for taking the time to answer my statement.
james

"Chris Cox" wrote in message

In article <uNxyb.32503$>,
james wrote:

Chris, check this link: http://www.cybercom.net/~dcoffin/resume.html It is Dave’s Resume’ and in it he states that his converter is used by several major commercial image programs including"Photoshop". As I

said,

Adobe’s Camera RAW converter is "based" on DCRAW and most likely refined

by

Adobe’s programmers.

I’m pretty sure that Photoshop’s code is not based on DCRAW (especially since I’ve seen our code go through several major revisions). Also, he claims to have his code used in other products that I know were developed quite independently.

About all we got from outside sources was details on a few of the undocumented tags (but most we had to decipher ourselves).
Chris

james wrote:

Ok Chris, I guess that Dave is just making a false claim that other raw decoders are based on his work.

Son, anyone can claim anything on a silly resume’.

Uni

Of course there is no way to really know is there? Adobe nor any of the other software developers that he mentions would not offer their version of raw conversion code for inspection, much less, give Dave credit for inspiration. Especially since his code has been publicly available for quite some time.
Thanks for taking the time to answer my statement.
james

"Chris Cox" wrote in message

In article <uNxyb.32503$>,
james wrote:

Chris, check this link: http://www.cybercom.net/~dcoffin/resume.html It is Dave’s Resume’ and in it he states that his converter is used by several major commercial image programs including"Photoshop". As I

said,

Adobe’s Camera RAW converter is "based" on DCRAW and most likely refined

by

Adobe’s programmers.

I’m pretty sure that Photoshop’s code is not based on DCRAW (especially since I’ve seen our code go through several major revisions). Also, he claims to have his code used in other products that I know were developed quite independently.

About all we got from outside sources was details on a few of the undocumented tags (but most we had to decipher ourselves).
Chris

"Uni" wrote in message

james wrote:

Ok Chris, I guess that Dave is just making a false claim that other raw decoders are based on his work.

Son, anyone can claim anything on a silly resume’.
Uni

No kidding? Really, I would never have believed that!
……………………….
I’m not that stupid to not know that. But, given the range of cameras that Dave’s software works with and how well it does work, and the length of time his code has been around, it is very possible that he is not making a false claim. It would not be the first time that a company has used someone else’s code in their own product and not given the original programmer credit. james

Update to older issue:

In message , I,
wrote:

In message ,
wrote:

In message <281120032209173035%>,
Chris Cox wrote:

Check the area being sampled by the eyedropper tool…
Other than that, I can’t reproduce what you’re seeing.

The eyedropper yields the same results – nonsense RGB values. A bright red pixel without a hint of green or blue in it might read:
R 170
G 216
B 200

And, as I said earlier, the update is extremely slow. The RGB info will stay frozen for up to 3 seconds after I move it to a new pixel. The whole GUI feels extremely sluggish compared to 7.01, and mouse events are routinely ignored, or the wrong tool shows under the cursor for a few seconds after placing it over a window.

Oh, yeah, this is the Windows version running under XP.

The sluggishness went away when I closed all the other programs. This is the first time in a very long time that I have ever had an app not respond because of what another app was doing. If it happens again, I’ll have to check the priorities of the programs.

I just realized what was really causing this. It wasn’t the other programs. What causes "info" to pause its update is the Browser, when the current browser directory is pointed to a CF or Memory Stick card in the reader. It does it to when the directory is on a floppy or hard disk, but only when reading it in when you first open it. With the removable flash storage, CPU usage spikes very frequently in Photoshop.

When is Photoshop finally going to get threaded like a 21st century program? You can’t even switch between Info, Navigator, and Histogram if they’re docked together.
—

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy

<<> <>>< <>>< ><<> <>>< ><<> ><<> <>><