How to convert image into Hex 2 Dimensional Array?

[Daniele Futtorovic]

On 5/8/2013 9:45 PM, Eric Sosman wrote:
On 5/8/2013 9:04 PM, Arne Vajhøj wrote:
On 5/8/2013 9:57 AM, lipska the kat wrote:
[...] the following two lines are
logically equivalent.

1. Byte[][] bytes = new Byte[width][height];
2. byte[][] bytes = new byte[width][length]

Not at all.

You will eventually end up with 1+width*height and 1 objects
respectively.

No; both will generate 1+width objects:

- One array containing `width' references to other arrays,

- `width' arrays containing `height' bytes or Byte
references.

A *really* stupid coder might use Byte[][] *and* populate
the arrays with `new Byte(value)' repeated `width*height' times;
that would produce `1 + width + width*height' objects in all.
Autoboxers would be unlikely to enter that particular trap --
but even so, a four- to eight-fold memory bloat is not to be
sneezed at.

Ooops.

1+width+width*height and 1+width objects.

I would still expect the byte version to end up
with width*height Byte objects.

If there are no null and no reused objects, then
I can not see how that can be avoided.

Are you saying that Java will intern so aggressively
that there will be reused objects?

Autoboxing will you Byte#valueOf, which returns pooled instances.

*will _use_

 

[Eric Sosman]

[...]

I would still expect the byte version to end up
with width*height Byte objects.

If there are no null and no reused objects, then
I can not see how that can be avoided.

Are you saying that Java will intern so aggressively
that there will be reused objects?

JLS, section 5.1.7:

"If the value p being boxed is true, false, a byte,
or a char in the range \u0000 to \u007f, or an int or
short number between -128 and 127 (inclusive), then let
r1 and r2 be the results of any two boxing conversions
of p. It is always the case that r1 == r2."

 

[Arne Vajhøj]

[...]

I would still expect the byte version to end up
with width*height Byte objects.

If there are no null and no reused objects, then
I can not see how that can be avoided.

Are you saying that Java will intern so aggressively
that there will be reused objects?

JLS, section 5.1.7:

"If the value p being boxed is true, false, a byte,
or a char in the range \u0000 to \u007f, or an int or
short number between -128 and 127 (inclusive), then let
r1 and r2 be the results of any two boxing conversions
of p. It is always the case that r1 == r2."

Ah - so max. 256 objects in case of auto boxing.

Arne

 

[Daniel Pitts]

[...]
I would still expect the byte version to end up
with width*height Byte objects.

If there are no null and no reused objects, then
I can not see how that can be avoided.

Are you saying that Java will intern so aggressively
that there will be reused objects?

JLS, section 5.1.7:

"If the value p being boxed is true, false, a byte,
or a char in the range \u0000 to \u007f, or an int or
short number between -128 and 127 (inclusive), then let
r1 and r2 be the results of any two boxing conversions
of p. It is always the case that r1 == r2."

Ah - so max. 256 objects in case of auto boxing.

If I'm reading that right, that is only 128 for bytes and chars. Every
byte with a high-bit set will be autoboxed to a new object.

I'm surprised by this actually. I can see the justification in chars,
but bytes I would have just go with the full 00 to FF

 

[Daniele Futtorovic]

On 5/8/2013 10:03 PM, Arne Vajhøj wrote:
[...]
I would still expect the byte version to end up
with width*height Byte objects.

If there are no null and no reused objects, then
I can not see how that can be avoided.

Are you saying that Java will intern so aggressively
that there will be reused objects?

JLS, section 5.1.7:

"If the value p being boxed is true, false, a byte,
or a char in the range \u0000 to \u007f, or an int or
short number between -128 and 127 (inclusive), then let
r1 and r2 be the results of any two boxing conversions
of p. It is always the case that r1 == r2."

Ah - so max. 256 objects in case of auto boxing.

If I'm reading that right, that is only 128 for bytes and chars. Every
byte with a high-bit set will be autoboxed to a new object.

I'm surprised by this actually. I can see the justification in chars,
but bytes I would have just go with the full 00 to FF

I don't think you're reading it right. Firstly, there's a comma after
"byte". Secondly, given how little sense Unicode notation makes for
bytes, it is doubtful that it should be meant to apply to them. And
finally, both the source code and Javadoc for Byte#valueOf are
unambiguous; to quote the latter: "all byte values are cached".

 

[Daniel Pitts]

On 5/8/2013 11:18 PM, Eric Sosman wrote:
On 5/8/2013 10:03 PM, Arne Vajhøj wrote:
[...]
I would still expect the byte version to end up
with width*height Byte objects.

If there are no null and no reused objects, then
I can not see how that can be avoided.

Are you saying that Java will intern so aggressively
that there will be reused objects?

JLS, section 5.1.7:

"If the value p being boxed is true, false, a byte,
or a char in the range \u0000 to \u007f, or an int or
short number between -128 and 127 (inclusive), then let
r1 and r2 be the results of any two boxing conversions
of p. It is always the case that r1 == r2."

Ah - so max. 256 objects in case of auto boxing.

If I'm reading that right, that is only 128 for bytes and chars. Every
byte with a high-bit set will be autoboxed to a new object.

I'm surprised by this actually. I can see the justification in chars,
but bytes I would have just go with the full 00 to FF

I don't think you're reading it right. Firstly, there's a comma after
"byte". Secondly, given how little sense Unicode notation makes for
bytes, it is doubtful that it should be meant to apply to them. And
finally, both the source code and Javadoc for Byte#valueOf are
unambiguous; to quote the latter: "all byte values are cached".

Eats, shoots, and leaves. Yes, I missed the comma. That totally makes
sense now. What threw me off the most was that they listed "values"
(true/false), then "a type" (byte), and then "values for types".

I might have worded it differently, but it is unambiguous as is.

I think my preferred structure would have been "If the value being boxed
is is a char in the range ... or is a short or int in the range ... or
is any boolean or byte value ..."

 

[Daniele Futtorovic]

On 5/9/13 7:05 PM, Arne Vajhøj wrote:
On 5/8/2013 11:18 PM, Eric Sosman wrote:
On 5/8/2013 10:03 PM, Arne Vajhøj wrote:
[...]
I would still expect the byte version to end up
with width*height Byte objects.

If there are no null and no reused objects, then
I can not see how that can be avoided.

Are you saying that Java will intern so aggressively
that there will be reused objects?

JLS, section 5.1.7:

"If the value p being boxed is true, false, a byte,
or a char in the range \u0000 to \u007f, or an int or
short number between -128 and 127 (inclusive), then let
r1 and r2 be the results of any two boxing conversions
of p. It is always the case that r1 == r2."

Ah - so max. 256 objects in case of auto boxing.
If I'm reading that right, that is only 128 for bytes and chars. Every
byte with a high-bit set will be autoboxed to a new object.

I'm surprised by this actually. I can see the justification in chars,
but bytes I would have just go with the full 00 to FF

I don't think you're reading it right. Firstly, there's a comma after
"byte". Secondly, given how little sense Unicode notation makes for
bytes, it is doubtful that it should be meant to apply to them. And
finally, both the source code and Javadoc for Byte#valueOf are
unambiguous; to quote the latter: "all byte values are cached".

Eats, shoots, and leaves. Yes, I missed the comma. That totally makes
sense now. What threw me off the most was that they listed "values"
(true/false), then "a type" (byte), and then "values for types".

I might have worded it differently, but it is unambiguous as is.

I think my preferred structure would have been "If the value being boxed
is is a char in the range ... or is a short or int in the range ... or
is any boolean or byte value ..."

True, that formulation would be clearer. Looks like they, in true
systematic fashion, went from the more simple to the more complex types.

 

[Arne Vajhøj]

On 5/9/13 7:05 PM, Arne Vajhøj wrote:
On 5/8/2013 11:18 PM, Eric Sosman wrote:
On 5/8/2013 10:03 PM, Arne Vajhøj wrote:
[...]
I would still expect the byte version to end up
with width*height Byte objects.

If there are no null and no reused objects, then
I can not see how that can be avoided.

Are you saying that Java will intern so aggressively
that there will be reused objects?

JLS, section 5.1.7:

"If the value p being boxed is true, false, a byte,
or a char in the range \u0000 to \u007f, or an int or
short number between -128 and 127 (inclusive), then let
r1 and r2 be the results of any two boxing conversions
of p. It is always the case that r1 == r2."

Ah - so max. 256 objects in case of auto boxing.
If I'm reading that right, that is only 128 for bytes and chars. Every
byte with a high-bit set will be autoboxed to a new object.

I'm surprised by this actually. I can see the justification in chars,
but bytes I would have just go with the full 00 to FF

I don't think you're reading it right. Firstly, there's a comma after
"byte". Secondly, given how little sense Unicode notation makes for
bytes, it is doubtful that it should be meant to apply to them. And
finally, both the source code and Javadoc for Byte#valueOf are
unambiguous; to quote the latter: "all byte values are cached".

Eats, shoots, and leaves. Yes, I missed the comma. That totally makes
sense now. What threw me off the most was that they listed "values"
(true/false), then "a type" (byte), and then "values for types".

I might have worded it differently, but it is unambiguous as is.

I think my preferred structure would have been "If the value being boxed
is is a char in the range ... or is a short or int in the range ... or
is any boolean or byte value ..."

I also missed the comma the first time I read it.

A bullet list would probably have made it more clear.

Arne

 

[Arne Vajhøj]

On 08/05/13 17:52, Joshua Cranmer 🧠wrote:
On 5/8/2013 1:30 AM, sout saret wrote:
Dear Community!

May you help me how to write code in java to convert image to Hex 2
dimensional array. I want to show format as below:

What format is this two-dimensional array? Looking from your code, you
appear to want it to be some sort of 256-byte pixel value, but are you
desiring:
1. 8-bit ARGB
2. 5-6-5 RGB
3. 8-bit grayscale
4. 32-bit ARGB
5. 24-bit RGB
6. Binary version of any widely-used image format, including but not
limited to PNG, BMP, GIF, JPG, XBM, TIF, and ICO.

I think he wants a byte for byte copy so the first byte gets copied into
[0][0] the next into [1][0] the next [2][0] etc until [width-1][0]
then start again at [0][1], [1][1], [2][1] etc etc

A byte for byte copy of what? I'm guessing the answer is the "pixel
matrix", but that's underdefined since pixels can take on many different
formats, which is what I was trying to get at--what encoding of a pixel
is desired?

I've been thinking about this and actually, in a byte for byte copy
the 'encoding' of a pixel is irrelevant.

If I open a (for example) jpg image in a hex viewer(ghex) all I see is
a bunch of bytes. As far as ghex is concerned that's all it is.
The bunch of bytes is only an image if it is interpreted as an image by
software that knows how to interpret the data *as an image*.

So, as far as reading the data goes, all we have is a stream of bytes.

If we want to store these bytes in a matrix(for whatever reason) we may
have an immediate problem. It may be the case that the byte count is not
a 'perfect square', what this means is that there may eventually be a
number matrix cells that will not contain data that is relevant to the
byte stream we are reading.

So, how do we determine where in the matrix our data ends and the
default values used to populate the arrays on creation begin?

If we use byte[][] we have a problem.
All byte values from 0x00 - 0xFF *could* be valid data,
byte arrays have each cell initialized to 0 (0x00)

Byte arrays however have each cell initialized to null.

It will therefore be very easy to determine the end of data in a
Byte[][] matrix. In a byte[][] matrix we would have to add some
information somewhere outside of the matrix.

This situation only really applies if we wish to store our bytes in a
matrix. Obviously this is *not* a problem if we store the bytes in a
single dimension array.

So, I'm not so sure that the original advice was as bad as all that, it
depends on the end usage of the stored data.

As ever I'd be interested in any comments.

Java 2D arrays are not necessarily square, so the second dimension
can be different for each element of the first dimension. So it
is also an option to use that instead of Byte[] with null fill
to end.

Arne

 

[Roedy Green]

May you help me how to write code in java to convert image to Hex 2 dimensional array. I want to show format as below:

I think your problem may be that you don't realize that internally the
image will be a matrix of ints or shorts. The hexness comes when you
display it or write it to text file.

see http://mindprod.com/jgloss/hex.html

 

[Arne Vajhøj]

On 08/05/13 19:54, Joshua Cranmer 🧠wrote:
On 5/8/2013 12:40 PM, lipska the kat wrote:
On 08/05/13 17:52, Joshua Cranmer 🧠wrote:
On 5/8/2013 1:30 AM, sout saret wrote:
Dear Community!

May you help me how to write code in java to convert image to Hex 2
dimensional array. I want to show format as below:

What format is this two-dimensional array? Looking from your code,
you
appear to want it to be some sort of 256-byte pixel value, but are
you
desiring:
1. 8-bit ARGB
2. 5-6-5 RGB
3. 8-bit grayscale
4. 32-bit ARGB
5. 24-bit RGB
6. Binary version of any widely-used image format, including but not
limited to PNG, BMP, GIF, JPG, XBM, TIF, and ICO.

I think he wants a byte for byte copy so the first byte gets copied
into
[0][0] the next into [1][0] the next [2][0] etc until [width-1][0]
then start again at [0][1], [1][1], [2][1] etc etc

A byte for byte copy of what? I'm guessing the answer is the "pixel
matrix", but that's underdefined since pixels can take on many
different
formats, which is what I was trying to get at--what encoding of a pixel
is desired?

I've been thinking about this and actually, in a byte for byte copy
the 'encoding' of a pixel is irrelevant.

If I open a (for example) jpg image in a hex viewer(ghex) all I see is
a bunch of bytes. As far as ghex is concerned that's all it is.
The bunch of bytes is only an image if it is interpreted as an image by
software that knows how to interpret the data *as an image*.

So, as far as reading the data goes, all we have is a stream of bytes.

If we want to store these bytes in a matrix(for whatever reason) we may
have an immediate problem. It may be the case that the byte count is not
a 'perfect square', what this means is that there may eventually be a
number matrix cells that will not contain data that is relevant to the
byte stream we are reading.

So, how do we determine where in the matrix our data ends and the
default values used to populate the arrays on creation begin?

If we use byte[][] we have a problem.
All byte values from 0x00 - 0xFF *could* be valid data,
byte arrays have each cell initialized to 0 (0x00)

Byte arrays however have each cell initialized to null.

It will therefore be very easy to determine the end of data in a
Byte[][] matrix. In a byte[][] matrix we would have to add some
information somewhere outside of the matrix.

This situation only really applies if we wish to store our bytes in a
matrix. Obviously this is *not* a problem if we store the bytes in a
single dimension array.

So, I'm not so sure that the original advice was as bad as all that, it
depends on the end usage of the stored data.

As ever I'd be interested in any comments.

Java 2D arrays are not necessarily square, so the second dimension
can be different for each element of the first dimension. So it
is also an option to use that instead of Byte[] with null fill
to end.

Now *that's* interesting.

I can't say I've done much with byte matrices or any other matrix for
that matter, or come to that, arrays, I generally tend to use dynamic
storage components, like LinkedList<> for example. this seems to compile.

byte[][] bytes = new byte[2][];
bytes[0] = new byte[10];
bytes[1] = new byte[7];

I didn't know you could do that.

Java only has this "array of array" or "jagged array".

The:

X[][] o = new X[m][n];

construct makes it looks different, but it is just syntactic sugar.

C# has both this type of array and a real 2D array (that is always
square).

Y[][] o = new Y[n][];
....

vs:

Y[,] o = new Y[n,m];

Arne

 

[Arne Vajhøj]

I think your problem may be that you don't realize that internally the
image will be a matrix of ints or shorts. The hexness comes when you
display it or write it to text file.

see http://mindprod.com/jgloss/hex.html

What does that have to do with the discussion??

Arne

 

[markspace]

What does that have to do with the discussion??

What discussion on cljp would be complete without random off-topic
interjaculations from Roedy?

 

[Arne Vajhøj]

What discussion on cljp would be complete without random off-topic
interjaculations from Roedy?

I guess you are right ....



Arne

 

[Roedy Green]

1On Sun, 12 May 2013 20:49:04 -0700, markspace

What discussion on cljp would be complete without random off-topic
interjaculations from Roedy?

It may be off topic from what you have been saying, but it is
perfectly on topic looking at the original post. Because of topic
drift I generally do not read threads before posting, just the
original.

 

[Roedy Green]

What discussion on cljp would be complete without random off-topic
interjaculations from Roedy?

You are beginning to sound like Lew. There are fewer and fewer people
participating simply because they don't want to deal with gratuitous
rudeness like that.