Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How to convert image into Hex 2 Dimensional Array?

Reply
Thread Tools

How to convert image into Hex 2 Dimensional Array?

 
 
Daniele Futtorovic
Guest
Posts: n/a
 
      05-09-2013
On 09/05/2013 04:09, Daniele Futtorovic allegedly wrote:
> On 09/05/2013 04:03, Arne Vajh°j allegedly wrote:
>> On 5/8/2013 9:59 PM, Arne Vajh°j wrote:
>>> 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_
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      05-09-2013
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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      05-10-2013
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.

Arne


 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      05-10-2013
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

 
Reply With Quote
 
Daniele Futtorovic
Guest
Posts: n/a
 
      05-10-2013
On 10/05/2013 18:46, Daniel Pitts allegedly wrote:
> 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".

--
DF.
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      05-10-2013
On 5/10/13 10:02 AM, Daniele Futtorovic wrote:
> On 10/05/2013 18:46, Daniel Pitts allegedly wrote:
>> 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 ..."
 
Reply With Quote
 
Daniele Futtorovic
Guest
Posts: n/a
 
      05-10-2013
On 10/05/2013 20:00, Daniel Pitts allegedly wrote:
> On 5/10/13 10:02 AM, Daniele Futtorovic wrote:
>> On 10/05/2013 18:46, Daniel Pitts allegedly wrote:
>>> 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.

--
DF.
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      05-10-2013
On 5/10/2013 2:00 PM, Daniel Pitts wrote:
> On 5/10/13 10:02 AM, Daniele Futtorovic wrote:
>> On 10/05/2013 18:46, Daniel Pitts allegedly wrote:
>>> 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

 
Reply With Quote
 
Arne Vajh├Şj
Guest
Posts: n/a
 
      05-11-2013
On 5/11/2013 4:28 AM, lipska the kat wrote:
> 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.

Arne


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      05-11-2013
On Tue, 7 May 2013 23:30:25 -0700 (PDT), sout saret
<(E-Mail Removed)> 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)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
To convert a one dimensional array into a two dimensional array using C amrutha0303 Software 0 08-03-2010 10:02 PM
Hex Color Codes - Hex 6 <=> Hex 3 lucanos@gmail.com HTML 10 08-18-2005 11:21 PM
How to convert an hex string to a Hex number chirs Javascript 3 12-01-2003 10:06 PM
hex(-5) => Futurewarning: ugh, can't we have a better hex than '-'[:n<0]+hex(abs(n)) ?? Bengt Richter Python 6 08-19-2003 07:33 AM



Advertisments