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

 

[Joerg Meier]

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

 

[Daniele Futtorovic]

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

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

 

[Jeff Higgins]

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]

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]

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.

 

[Jeff Higgins]

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 ðŸ§]

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.

 

[Daniele Futtorovic]

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

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.

 

[Eric Sosman]

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.

 

[Joshua Cranmer ðŸ§]

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.

 

[Joshua Cranmer ðŸ§]

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

 

[Daniel Pitts]

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.

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]

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

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;

There was no such implication, you are mistaken.

Okay, whatever.

 

[Manuel Dahmen]

Le mercredi 8 mai 2013 08:30:25 UTC+2, sout saret a écrit :

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

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]

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]

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

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

 

[Arne Vajhøj]

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

Arne

 

[Arne Vajhøj]

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?

Arne