How to convert image into Hex 2 Dimensional Array?

[sout saret]

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:

{
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x1B,0xFB,0x12,0x0A,0x1B,0x0B,0x09,0x09,0x19,0x09,0x19,0x29,0x19,0xE9,0x00,0x20,0x00,0x60,0x00,0x00,0x00,0x00,0x00,0x00,},
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x6D,0xFD,0x48,0x05,0x6D,0xF5,0x25,0x14,0x25,0x15,0x25,0x15,0xFD,0x15,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
{0x00,0xC0,0x01,0x00,0x01,0xC0,0x00,0x00,0xBC,0x78,0x24,0x48,0xA4,0x48,0xA4,0x48,0xB4,0x48,0xB5,0x48,0xB6,0xC8,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
};

Best Regard!

Saret Sout

[lipska the kat]

On 08/05/13 07:30, 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:

[snip]

hmm, sounds like homework.

1. get hold of the javadoc for your chosen Java version

Then ...

To get you started.

import javax.swing.ImageIcon;

public class ImageToHex {

public static void main(String[] args) {

ImageIcon ii = new ImageIcon("/path/to/image.ext");
Integer width = ii.getIconWidth();
Integer height = ii.getIconHeight();
Byte[][] bytes = new Byte[width][height];
//you now have 2 dimensional array into which
//you can read your image bytes
//the rest is up to you I guess
}
}

I'm sure there are other/better ways of doing it

lipska

--
Lipska the Kat�: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[Joerg Meier]

On Wed, 08 May 2013 09:06:09 +0100, lipska the kat wrote:

> On 08/05/13 07:30, sout saret wrote:
>> 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:
> [snip]

> hmm, sounds like homework.

It sounded more like he wanted to hardcode an image into his class files,
which is a fantastically terrible idea that's usually attempted by people
who decided that loading resources in jar files is too complicated to
figure out, which is why I stayed away ;)

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[lipska the kat]

On 08/05/13 11:29, Joerg Meier wrote:
> On Wed, 08 May 2013 09:06:09 +0100, lipska the kat wrote:
>
>> On 08/05/13 07:30, sout saret wrote:
>>> 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:
>> [snip]
>
>> hmm, sounds like homework.
>
> It sounded more like he wanted to hardcode an image into his class files,
> which is a fantastically terrible idea that's usually attempted by people
> who decided that loading resources in jar files is too complicated to
> figure out, which is why I stayed away ;)

Eek, surely not

[Daniele Futtorovic]

On 08/05/2013 10:06, lipska the kat allegedly wrote:
> Byte[][] bytes = new Byte[width][height];

Lipska, mind the difference between Byte and byte. That code above is
extremely bad advice.

--
DF.

[lipska the kat]

Why? it's common practice these days to eschew primitives and use
(autoboxing) classes, it's more consistent in OO code and, as I
understand things, post autoboxing, the following two lines are
logically equivalent.

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

The following is perfectly legal given either of the above

byte b = 127;
bytes[0][0] = b;
Byte c = 126;
bytes[0][1] = c;
Byte d = bytes[0][0];
byte e = bytes[0][1];

I would of course be interested to know what your objection is.

Also, I seem to remember being 'told off' for using primitives a while
back ... ho hum.

[Jeff Higgins]

On 05/08/2013 02: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:
>

You've asked too much for a simple usenet post.
You might read the article here:
<http://www.developer.com/java/other/article.php/3403921>
It's a pretty long article but at the end you should
understand how to get the image data and then you will
only need to figure out how to represent it as a hex string

[Daniel Pitts]

On 5/8/13 6:57 AM, lipska the kat wrote:
> On 08/05/13 14:19, Daniele Futtorovic wrote:
>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
>>> Byte[][] bytes = new Byte[width][height];
>>
>> Lipska, mind the difference between Byte and byte. That code above is
>> extremely bad advice.
>
> Why? it's common practice these days to eschew primitives and use
> (autoboxing) classes

Common practice where? Cite a credible source or I'll be forced to think
that you are just making up facts to support your mistake. My 4 year
old daughter does that; you want to be more credible than my 4 year old,
don't you?

> it's more consistent in OO code and, as I
> understand things, post autoboxing, the following two lines are
> logically equivalent.
>
> 1. Byte[][] bytes = new Byte[width][height];
> 2. byte[][] bytes = new byte[width][length]

Even ignoring the typos, those are nothing alike.

Auto-boxing is a convenience, but does not make those two things the
same, even by a long shot.

byte cannot contain a NULL reference. It contains no reference
whatsoever. Byte on the other hand *can* contain a reference.

byte[] is *not* assignable to Byte[], and Byte[] is *not* assignable to
byte[].

You also cannot use arrayCopy to copy between the two.

Boxing and Unboxing (whether manual or automatic) *does* have a cost. It
may be minimal, and shouldn't be the only consideration. It should
however be noted and considered as part of the choice.

Personally my decision on whether to use Byte vs byte would hinge solely
on the question "do I want to store nulls in this?"

Also, I would likely wrap that primitive value in a semantic class. I
still lament that Java doesn't have "value types" other than the
predefined primitives, but I have learned to be "okay" with that.

[Daniele Futtorovic]

On 08/05/2013 15:57, lipska the kat allegedly wrote:
> On 08/05/13 14:19, Daniele Futtorovic wrote:
>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
>>> Byte[][] bytes = new Byte[width][height];
>>
>> Lipska, mind the difference between Byte and byte. That code above is
>> extremely bad advice.
>
> Why? it's common practice these days to eschew primitives and use
> (autoboxing) classes, it's more consistent in OO code and, as I
> understand things, post autoboxing, the following two lines are
> logically equivalent.
>
> 1. Byte[][] bytes = new Byte[width][height];
> 2. byte[][] bytes = new byte[width][length]
>
> The following is perfectly legal given either of the above
>
> byte b = 127;
> bytes[0][0] = b;
> Byte c = 126;
> bytes[0][1] = c;
> Byte d = bytes[0][0];
> byte e = bytes[0][1];
>
> I would of course be interested to know what your objection is.

Simple: "byte[]" is not a primitive type. "byte" is a primitive type.
"byte[]" is a reference type.

Along the same lines, you'll be hard pressed to find a Java I/O library
that uses Byte[]'s rather than byte[]'s.

> Also, I seem to remember being 'told off' for using primitives a while
> back ... ho hum.

I don't know about that.

--
DF.

[lipska the kat]

On 08/05/13 16:22, Daniel Pitts wrote:
> On 5/8/13 6:57 AM, lipska the kat wrote:
>> On 08/05/13 14:19, Daniele Futtorovic wrote:
>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
>>>> Byte[][] bytes = new Byte[width][height];
>>>
>>> Lipska, mind the difference between Byte and byte. That code above is
>>> extremely bad advice.
>>
>> Why? it's common practice these days to eschew primitives and use
>> (autoboxing) classes
> Common practice where? Cite a credible source or I'll be forced to think
> that you are just making up facts to support your mistake. My 4 year
> old daughter does that; you want to be more credible than my 4 year old,
> don't you?

Think what you like, your opinion of my credibility is of no importance
to me.

In the context of the OPs question, why is it bad advice to suggest
Byte[][] as opposed to byte[][]

[snip]

> Personally my decision on whether to use Byte vs byte would hinge solely
> on the question "do I want to store nulls in this?
> Also, I would likely wrap that primitive value in a semantic class.

What primitive value? a byte?
There is already a wrapper class, it's called Byte ???

[lipska the kat]

On 08/05/13 16:32, Daniele Futtorovic wrote:
> On 08/05/2013 15:57, lipska the kat allegedly wrote:
>> On 08/05/13 14:19, Daniele Futtorovic wrote:
>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
>>>> Byte[][] bytes = new Byte[width][height];
>>>
>>> Lipska, mind the difference between Byte and byte. That code above is
>>> extremely bad advice.
>>
>> Why? it's common practice these days to eschew primitives and use
>> (autoboxing) classes, it's more consistent in OO code and, as I
>> understand things, post autoboxing, the following two lines are
>> logically equivalent.
>>
>> 1. Byte[][] bytes = new Byte[width][height];
>> 2. byte[][] bytes = new byte[width][length]

typo notwithstanding oops :-(

>> The following is perfectly legal given either of the above
>>
>> byte b = 127;
>> bytes[0][0] = b;
>> Byte c = 126;
>> bytes[0][1] = c;
>> Byte d = bytes[0][0];
>> byte e = bytes[0][1];
>>
>> I would of course be interested to know what your objection is.
>
> Simple: "byte[]" is not a primitive type.

I wasn't aware that I said it was

> "byte" is a primitive type.
> "byte[]" is a reference type.

no argument there but what is your *objection* to

Byte[][] bytes = new Byte[width][height];

in the context of the OPs question?

[Jeff Higgins]

On 05/08/2013 04:06 AM, lipska the kat wrote:
> On 08/05/13 07:30, 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:
>
> [snip]
>
> hmm, sounds like homework.

hmm. Sounds like the beginning of another snarky reply.

>
> 1. get hold of the javadoc for your chosen Java version
>
> Then ...
>
> To get you started.
>
> import javax.swing.ImageIcon;
>
> public class ImageToHex {
>
> public static void main(String[] args) {
>
> ImageIcon ii = new ImageIcon("/path/to/image.ext");
> Integer width = ii.getIconWidth();
> Integer height = ii.getIconHeight();
> Byte[][] bytes = new Byte[width][height];
> //you now have 2 dimensional array into which
> //you can read your image bytes
> //the rest is up to you I guess
> }
> }
>
> I'm sure there are other/better ways of doing it
>

WTF Why bother?

[Joshua Cranmer 🐧]

On 5/8/2013 8:57 AM, lipska the kat wrote:
> Why? it's common practice these days to eschew primitives and use
> (autoboxing) classes, it's more consistent in OO code and, as I
> understand things, post autoboxing, the following two lines are
> logically equivalent.
>
> 1. Byte[][] bytes = new Byte[width][height];

This creates an array with every entry prefilled to NULL.

> 2. byte[][] bytes = new byte[width][length]

This creates an array with every entry prefilled to 0.

Ergo, not logically equivalent, even if I assume that your height/length
was a typo.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

[Daniele Futtorovic]

When I called out your using a Byte[] rather than byte[] in your example
code, you defended it on the grounds of an alleged "common practice" to
use (boxed) reference types instead of primitive types. Thereby, you
have implied that byte[] was a primitive type; otherwise your whole
argument would have been a non sequitur.

But byte[] is not a primitive type, and hence your argument,
irrespectively of its merits (see below), does not apply.

>> "byte" is a primitive type.
>> "byte[]" is a reference type.
>
> no argument there but what is your *objection* to
>
> Byte[][] bytes = new Byte[width][height];
>
> in the context of the OPs question?

Objection? It's bullcrap. Firstly, no I/O library uses Byte[]. Secondly,
as Daniel has indicated, the only reason to use Byte[] over byte[] would
be to store null references. Which the OP doesn't need, as they have
actual data. And lastly, it's dangerous because it furthers the very
thing that, I reckon, lead you to use it in the first place: the
confusion induced by autoboxing.

General OO matters set aside, in the context of Java, autoboxing is a
poison. The meagre convenience it provides is largely offset by the
confusion, or lack of clarity, it causes in the minds of Java
programmers, especially aspirant Java programmers. I've witnessed its
nefarious effects countless times in my colleagues' code. A for/each
loop is exactly the same thing as a normal for loop with an iterator.
But, for better or for worse, in Java, a boxed reference type and a
primitive type are two completely different things. Autoboxing induces
the thought that they're not. That's why it's poison.

--
DF.

[lipska the kat]

On 08/05/13 16:22, Daniel Pitts wrote:

> On 5/8/13 6:57 AM, lipska the kat wrote:
>> On 08/05/13 14:19, Daniele Futtorovic wrote:
>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
>>>> Byte[][] bytes = new Byte[width][height];
>>>
>>> Lipska, mind the difference between Byte and byte. That code above is
>>> extremely bad advice.
>>
>> Why? it's common practice these days to eschew primitives and use
>> (autoboxing) classes
> Common practice where? Cite a credible source or I'll be forced to think
> that you are just making up facts to support your mistake. My 4 year
> old daughter does that; you want to be more credible than my 4 year old,
> don't you?

Hmm

http://docs.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html

<cite>
So when should you use autoboxing and unboxing? Use them only when there
is an �impedance mismatch� between reference types and primitives, for
example, when you have to put numerical values into a collection. It is
not appropriate to use autoboxing and unboxing for scientific computing,
or other performance-sensitive numerical code. An Integer is not a
substitute for an int; autoboxing and unboxing blur the distinction
between primitive types and reference types, but they do not eliminate it.
</cite>

So, I'll agree that my assertion of logical equivalence is bollocks
However I'm still not convinced that mixing primitives and reference
types is a 'good idea' in OO code.

But given the above I'll concede that suggesting Byte[][] was possibly
poor advice, byte[][] might be better.


[snip]

--
Lipska the Kat�: Troll hunter, sandbox destroyer

[Joshua Cranmer 🐧]

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.

[Eric Sosman]

On 5/8/2013 11:22 AM, Daniel Pitts wrote:
> On 5/8/13 6:57 AM, lipska the kat wrote:
>> On 08/05/13 14:19, Daniele Futtorovic wrote:
>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
>>>> Byte[][] bytes = new Byte[width][height];
>>>
>>> Lipska, mind the difference between Byte and byte. That code above is
>>> extremely bad advice.
>>
>> Why? it's common practice these days to eschew primitives and use
>> (autoboxing) classes
> Common practice where? Cite a credible source or I'll be forced to think
> that you are just making up facts to support your mistake. My 4 year
> old daughter does that; you want to be more credible than my 4 year old,
> don't you?
>
>> it's more consistent in OO code and, as I
>> understand things, post autoboxing, the following two lines are
>> logically equivalent.
>>
>> 1. Byte[][] bytes = new Byte[width][height];
>> 2. byte[][] bytes = new byte[width][length]
>
> Even ignoring the typos, those are nothing alike.
>
> Auto-boxing is a convenience, but does not make those two things the
> same, even by a long shot.

For example, consider what happens when `int x = bytes[0][0];'
immediately follows either of the above. In case 2, it sets x
to zero. In case 1, the JVM throws NullPointerException. That's
not "logically equivalent" in my book!

>[...]

> Personally my decision on whether to use Byte vs byte would hinge solely
> on the question "do I want to store nulls in this?"

Or on "Do I want to put it in a Collection?"

There's also the matter of the memory footprint, even if
"efficiency" is a dirty word in some circles. Version 1 will
use four times (32-bit JVM) or eight times (64-bit) as much
memory as version 2. Image sizes vary, but even a fairly modest
640x480 has 300K pixels -- so using Byte[][] instead of byte[][]
would cost an extra 0.9MB or 2.1MB. Even if I had the desire to
store nulls, a bloat of such proportions would probably prompt
me to use byte[][] and seek another way to represent whatever
I wanted the nulls to stand for.

--
Eric Sosman
eso...@comcast-dot-net.invalid

[lipska the kat]

There was no such implication, you are mistaken.

I have admitted elsewhere that it was 'less than optimal' to suggest
Byte[][]. I did it for purely 'OO' reasons.

Interesting reactions though.

[lipska the kat]

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

[lipska the kat]

On 08/05/13 17:43, Jeff Higgins wrote:
> On 05/08/2013 04:06 AM, lipska the kat wrote:
>> On 08/05/13 07:30, 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:
>>
>> [snip]
>>
>> hmm, sounds like homework.
>
> hmm. Sounds like the beginning of another snarky reply.

Hmm, wrong again I see.

>>
>> 1. get hold of the javadoc for your chosen Java version

[snip]

>> I'm sure there are other/better ways of doing it
>>
>
> WTF Why bother?

Because unlike others in this group I don't think I'm perfect.

[Joshua Cranmer 🐧]

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?

Things get even more fun if you don't want an RGB colorspace--HSL is
often better for manipulation, but YCbCr or CIELAB are more
representative of how the human eye perceives color and are used in
lossy compression and scientific image processing, for that reason.
Also, even just RGB is a meaningless term because there are several
different RGB colorspaces, the most common being sRGB and Adobe RGB.

If you just want to statically convert an image into this format for use
as an internal resource, I'd recommend not coding it in Java but using
ImageMagick to convert the image to something like PBM which specifies
the pixel data in a simple ASCII format:
<http://en.wikipedia.org/wiki/Netpbm_format>.

[lipska the kat]

Good question, back to the OP I guess

Also, I made an error in assuming the array is dimensioned by getting
the width in pixels * the height in pixels ... so all in all not such a
good example :-)

ho hum.

[Daniel Pitts]

On 5/8/13 9:03 AM, lipska the kat wrote:
> On 08/05/13 16:22, Daniel Pitts wrote:
>> On 5/8/13 6:57 AM, lipska the kat wrote:
>>> On 08/05/13 14:19, Daniele Futtorovic wrote:
>>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
>>>>> Byte[][] bytes = new Byte[width][height];
>>>>
>>>> Lipska, mind the difference between Byte and byte. That code above is
>>>> extremely bad advice.
>>>
>>> Why? it's common practice these days to eschew primitives and use
>>> (autoboxing) classes
>> Common practice where? Cite a credible source or I'll be forced to think
>> that you are just making up facts to support your mistake. My 4 year
>> old daughter does that; you want to be more credible than my 4 year old,
>> don't you?
>
> Think what you like, your opinion of my credibility is of no importance
> to me.
>
> In the context of the OPs question, why is it bad advice to suggest
> Byte[][] as opposed to byte[][]
>
> [snip]

Given in the part you snipped. Try again.

>
>> Personally my decision on whether to use Byte vs byte would hinge solely
>> on the question "do I want to store nulls in this?
>> Also, I would likely wrap that primitive value in a semantic class.
>
> What primitive value? a byte?
> There is already a wrapper class, it's called Byte ???

The "Byte" class is a primitive wrapper. I would wrap it with a semantic
class which determines what that byte represents. Although, I wouldn't
be likely to write that for a byte, but other primitives I would.

[Daniele Futtorovic]

Okay, whatever.

--
DF.

[Manuel Dahmen]

You should have a look in the javadoc at the BufferedImage class.

Method getRGB(int x, int y)
or
getRed() getGreen() getBlue() getAlpha()

and then loop and output in hex format.

Seems trivial.

[Arne Vajhøj]

On 5/8/2013 9:57 AM, lipska the kat wrote:
> On 08/05/13 14:19, Daniele Futtorovic wrote:
>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
>>> Byte[][] bytes = new Byte[width][height];
>>
>> Lipska, mind the difference between Byte and byte. That code above is
>> extremely bad advice.
>
> Why? it's common practice these days to eschew primitives and use
> (autoboxing) classes,

No - it is not.

And especially not when it comes to arrays.

> it's more consistent in OO code and, as I
> understand things, post autoboxing, 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.

> The following is perfectly legal given either of the above
>
> byte b = 127;
> bytes[0][0] = b;
> Byte c = 126;
> bytes[0][1] = c;
> Byte d = bytes[0][0];
> byte e = bytes[0][1];

Yes.

But the fact that you can make those assignments does not
make the two declarations equivalent.

> I would of course be interested to know what your objection is.

Typically you want value semantics for a case like this.

And all those objects will come with significant overhead (which may
be important in some contexts).

> Also, I seem to remember being 'told off' for using primitives a while
> back ... ho hum.

If someone said that for a case like this, then you have been listening
to the wrong person.

Arne

[Arne Vajhøj]

Good.

> However I'm still not convinced that mixing primitives and reference
> types is a 'good idea' in OO code.

I would expect almost any Java program to use both ref types and
value types.

And the equivalent in C#.

Lots of generic collection code and ORM code even mixes primitives
with their ref type wrappers, because that is necessary in the
context (Java implementation of generics and databases NULL values).

Arne

[Eric Sosman]

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.

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Arne Vajhøj]

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.

Arne

[Arne Vajhøj]

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

Arne

[Daniele Futtorovic]

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

--
DF.

[Daniele Futtorovic]

*will _use_

[Eric Sosman]

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."

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Arne Vajhøj]

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

Arne

[Daniel Pitts]

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]

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".

--
DF.

[Daniel Pitts]

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]

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

--
DF.

[Arne Vajhøj]

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

A bullet list would probably have made it more clear.

Arne

[lipska the kat]

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.

[Arne Vajhøj]

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

[lipska the kat]

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.

Well there you are, If I had ignored this thread I wouldn't have learned
that.

comp.lang.java.programmer, gotta love it.

[Roedy Green]

On Tue, 7 May 2013 23:30:25 -0700 (PDT), sout saret
<saret...@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>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
--
Roedy Green Canadian Mind Products http://mindprod.com
Nothing is so good as it seems beforehand.
~ George Eliot (born: 1819-11-22 died: 1880-12-22 at age: 61) (Mary Ann Evans)

[Arne Vajhøj]

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]

On 5/11/2013 4:33 PM, Roedy Green wrote:
> On Tue, 7 May 2013 23:30:25 -0700 (PDT), sout saret
> <saret...@gmail.com> wrote, quoted or indirectly quoted someone who
> said :
>
>> 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

What does that have to do with the discussion??

Arne

[markspace]

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

[Arne Vajhøj]

I guess you are right ....

:-)

Arne

[Roedy Green]

1On Sun, 12 May 2013 20:49:04 -0700, markspace
<mark...@nospam.nospam> wrote, quoted or indirectly quoted someone
who said :

>

>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]

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

<mark...@nospam.nospam> wrote, quoted or indirectly quoted someone
who said :

>

>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.