Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23918 > unrolled thread

How to convert image into Hex 2 Dimensional Array?

Back to article view | Back to comp.lang.java.programmer

Contents

  How to convert image into Hex 2 Dimensional Array? sout saret <saretmis097@gmail.com> - 2013-05-07 23:30 -0700
    Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 09:06 +0100
      Re: How to convert image into Hex 2 Dimensional Array? Joerg Meier <joergmmeier@arcor.de> - 2013-05-08 12:29 +0200
        Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 13:28 +0100
      Re: How to convert image into Hex 2 Dimensional Array? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-08 15:19 +0200
        Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 14:57 +0100
          Re: How to convert image into Hex 2 Dimensional Array? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-08 08:22 -0700
            Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 17:03 +0100
              Re: How to convert image into Hex 2 Dimensional Array? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-08 13:44 -0700
            Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 17:48 +0100
              Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-08 21:10 -0400
            Re: How to convert image into Hex 2 Dimensional Array? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-05-08 12:52 -0400
          Re: How to convert image into Hex 2 Dimensional Array? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-08 17:32 +0200
            Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 17:17 +0100
              Re: How to convert image into Hex 2 Dimensional Array? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-08 18:46 +0200
                Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 18:25 +0100
                  Re: How to convert image into Hex 2 Dimensional Array? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-08 23:24 +0200
          Re: How to convert image into Hex 2 Dimensional Array? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-05-08 11:46 -0500
          Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-08 21:04 -0400
            Re: How to convert image into Hex 2 Dimensional Array? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-05-08 21:45 -0400
              Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-08 21:59 -0400
                Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-08 22:03 -0400
                  Re: How to convert image into Hex 2 Dimensional Array? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-09 04:09 +0200
                    Re: How to convert image into Hex 2 Dimensional Array? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-09 04:09 +0200
                  Re: How to convert image into Hex 2 Dimensional Array? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-05-08 23:18 -0400
                    Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-09 22:05 -0400
                      Re: How to convert image into Hex 2 Dimensional Array? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-10 09:46 -0700
                        Re: How to convert image into Hex 2 Dimensional Array? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-10 19:02 +0200
                          Re: How to convert image into Hex 2 Dimensional Array? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-10 11:00 -0700
                            Re: How to convert image into Hex 2 Dimensional Array? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-10 23:42 +0200
                            Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-10 18:20 -0400
      Re: How to convert image into Hex 2 Dimensional Array? Jeff Higgins <jeff@invalid.invalid> - 2013-05-08 12:43 -0400
        Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 18:45 +0100
    Re: How to convert image into Hex 2 Dimensional Array? Jeff Higgins <jeff@invalid.invalid> - 2013-05-08 11:18 -0400
    Re: How to convert image into Hex 2 Dimensional Array? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-05-08 11:52 -0500
      Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 18:40 +0100
        Re: How to convert image into Hex 2 Dimensional Array? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-05-08 13:54 -0500
          Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-08 20:43 +0100
          Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-11 09:28 +0100
            Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-11 08:50 -0400
              Re: How to convert image into Hex 2 Dimensional Array? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-11 15:00 +0100
                Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-12 21:45 -0400
    Re: How to convert image into Hex 2 Dimensional Array? Manuel Dahmen <manuel.dahmen@gmail.com> - 2013-05-08 15:38 -0700
    Re: How to convert image into Hex 2 Dimensional Array? Roedy Green <see_website@mindprod.com.invalid> - 2013-05-11 13:33 -0700
      Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-12 21:48 -0400
        Re: How to convert image into Hex 2 Dimensional Array? markspace <markspace@nospam.nospam> - 2013-05-12 20:49 -0700
          Re: How to convert image into Hex 2 Dimensional Array? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-13 19:08 -0400
          Re: How to convert image into Hex 2 Dimensional Array? Roedy Green <see_website@mindprod.com.invalid> - 2013-05-15 03:45 -0700
          Re: How to convert image into Hex 2 Dimensional Array? Roedy Green <see_website@mindprod.com.invalid> - 2013-05-15 03:50 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#23954

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.

Arne

[toc] | [prev] | [next] | [standalone]

#23955

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?

Arne

[toc] | [prev] | [next] | [standalone]

#23956

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.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#23957

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_

[toc] | [prev] | [next] | [standalone]

#23958

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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#23978

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

[toc] | [prev] | [next] | [standalone]

#23984

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

[toc] | [prev] | [next] | [standalone]

#23986

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.

[toc] | [prev] | [next] | [standalone]

#23988

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

[toc] | [prev] | [next] | [standalone]

#23998

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.

[toc] | [prev] | [next] | [standalone]

#24001

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

[toc] | [prev] | [next] | [standalone]

#23933

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?

[toc] | [prev] | [next] | [standalone]

#23941

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.

lipska

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

[toc] | [prev] | [next] | [standalone]

#23925

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

[toc] | [prev] | [next] | [standalone]

#23937

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.
-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#23940

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

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

[toc] | [prev] | [next] | [standalone]

#23944

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

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#23945

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?

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.

lipska

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

[toc] | [prev] | [next] | [standalone]

#24005

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.

lipska

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

[toc] | [prev] | [next] | [standalone]

#24006

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web