Colour Picker

[fazstp]

This is an alternative to the getPixel by histogram method. It's probably overkill for a single pixel but might be useful for more intensive image analysis.

Edit: Ok cool. The linefeed conversion doesn't seem to occur when reading the whole file. Here's v2.

[fazstp]

Speaking of image analysis there seems to be a problem.

This code;

rgbStr = temp.read( 3 );
r = rgbStr.charCodeAt( 0 );
g = rgbStr.charCodeAt( 1 );
b = rgbStr.charCodeAt( 2 );

sometimes returns values over 255. Don't char codes only go up to 255?

[xbytor]

Characters in JS are Unicode. If I remember correctly, they are usually UTF-8 which means that if the stream doesn't have any 16bit unicode characters it looks like a traditional 8bit character stream. charCodeAt will return a 16bit unicode character regardless of what the underlying stream is.

Now the question here is why does there appear to be unicode characters in your string. The problem can be found in the file encoding. If you just open the file and read it in, it uses something like the UTF-8 encoder. That means if it sees something like a 16bit unicode character in the file, thats what you get. It consumes the next byte in the stream to create that character. Also, it does all kinds of fun CR/LF conversions which create even more havoc.

If you are reading binary data, you need to use the BINARY encoder. In your code, that means changing this code

Code: Select all    temp = new File( Folder.temp.fsName + 'Temp.raw' );
    temp.open( 'e' );
    temp.seek( 3 * ((varY * width) + varX), 0 );


to this code:

Code: Select all    temp = new File( Folder.temp.fsName + 'Temp.raw' );
    temp.open( 'e' );
    temp.encoding = 'BINARY';
    temp.seek( 3 * ((varY * width) + varX), 0 );


One painful thing to note is that PS7 does not have BINARY mode. The biggest problem turns out to be the CR/LF code. If you really need to do binary work on PS7, let me know and I'll dig it out.

-X

[fazstp]

Wouldn't you know it, I am using PS7. I tried the BINARY thing and it did stop the error so does that mean it may be implemented? I was short two pixels when I processed an entire image. Not sure if it's due to the LF thing.

[xbytor]

I found the code I used to handle writing binary files in PS7. This is a true geek-hack.

Code: Select allStdlib.writeToFile = function(fptr, str, encoding) {
  var file = Stdlib.convertFptr(fptr);

  file.open("w") || throwFileError(file, "Unable to open output file ");
  if (encoding) {
    file.encoding = encoding;
  }

  if (isPS7() && encoding == 'BINARY') {
    file.lineFeed = 'unix';

    var pos = 0;
    var cr = '\r';
    var next;
    while ((next = str.indexOf(cr, pos)) != -1) {
      file.write(str.substring(pos, next));
      file.lineFeed = 'mac';
      file.write(cr);
      file.lineFeed = 'unix';
      pos = next + 1;
    }
    if (pos < str.length) {
      file.write(str.substring(pos));
    }
  } else {
    file.write(str);
  }
  file.close();
};

It may be the case (judging from the code) that PS7 does handle binary files (except for CRLF translation) because there is no en/decoding done when BINARY is specifed except for CRLF. Open up an existing text file in PS7 and see what it's default encoding is.

To test you have a CRLF problem, read the file in like you currently are, then write it out to a new file using the function above. If the files are not identical in length, your missing pixels are probably CRLF related. To verify that this is the case, look at the files in a binary editor to determine where the problem is. If the files are identical in length, compare the files using whatever tools you have availble to compare binary files. There still maybe a CR->LF conversion problem in there. The bytes you need to be concerned about in both cases are 0x0D and 0x0A.


If it is a CRLF translation problem (and the two missing pixels seem to indicate that it may be) you'll need to implement a 'read' version of the function above.
To do that, you'd need to
1) open the file and set to BINARY mode
2) set file.lineFeed to unix
3) read a character at a time.
4) if its a \n (x0A) change the lineFeed more to 'mac' and read it again. If it is now a \r (x0D) a translation is occuring and the character probably really is a \r.
5) change the lineFeed back to unix and go on to the next character.

Let me know what you find out.

-X

[fazstp]

The problem seems to be that char 13 is read as char 10 and char 13-10 pairs are read as 10 dropping the extra char, hence the missing pixels.

[Mike Hale]

I don't think the Photoshop raw format has line feeds. At least the file I saved as raw then checked with a binary editor did not have any 0x0D or 0x0A bytes.

I think that it is reading pixel data as line feeds

[fazstp]

Yes that's the trouble. Some pixels just happen to have rgb values of 10 or 13.

[xbytor]

fazstp wrote:The problem seems to be that char 13 is read as char 10 and char 13-10 pairs are read as 10 dropping the extra char, hence the missing pixels.

OK. A bit different than I was expecting but not completely unexpected. So any time you read a \r (13) you file.seek() to the next character and readch() instead of simply doing a readch() from the current file position. This is managable. Let me know if you if you have problems getting this coded.

-X

[fazstp]

Thanks X, I can get around it. It just means the rgb value for that pixel will be out. I guess I could do a pre-check select color range to see if there are any 13s.