On 25/7/06 15:04, Joel Guillod wrote:
For image processing I have to extract the RGB values from an imagedata
of an image but I got different results under MacOSX and Win32.
I found that the imagedata values is different between the two platform:
every color component of pixels is slighty change
Malte,
Thanks for testing. It sounds like using high quality JPEG files is
still the way to go.
best,
Chipp
On 7/25/06, Malte Brill <[EMAIL PROTECTED]> wrote:
I tested it again and it seems it doesn´t work.
___
use-revolution mailing list
use-revol
Hi Chipp,
I tested it again and it seems it doesn´t work. Seems I have a
screwed up memory at the moment. I know I had it working when
exporting from my OS 9 machine which is dead now I´m afraid. I recall
that I had a jpeg with embedded color profile in the back instead of
a card backgrou
Hi Malte,
I did download and try SuperPNG (turns out it's FREE), but could not
get it to create the correct gamma settings. Can you share your
secret?
Thx,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to s
Malte,
Are you saying when using this plugin, there is no difference between
PNG files (gamma-wise) between platforms? If that's true, then you are
wonderful!!!
(Even if it's not true, you're still wonderful ;-)
Could you possibly post a stack which would demonstrate this? Here's
what I would s
Chipp wrote:
If you don't need the alpha channel of PNGs, I suggest always using
JPGs.
And if you need the alpha channel and work with a graphic app that
can use Photoshop plugins try superpng, which can embed the correct
gamma settings into the png files. I used to work with it a lot and
Ian,
That is a good guess. Perhaps Joel can check images imported as JPG vs
PNG. I know, for instance, if you are trying to match a background
color on a stack, you should use JPG's and not PNGs because of the
gamma-correction of PNGs. If you don't need the alpha channel of PNGs,
I suggest alway
Joel,
The big endian, little endian byte-order issue between platforms went
away back in 2.2. I used to have to check for it before doing any
imageData manipulation. I no longer have to.
I don't think the imagedata has changed, and my thought would be to
check and make sure the images are set to
Only thing I can think of off-hand is that it was a PNG image and the
automatic gamma-correction of the format was kicking in.
Ian
On 25 Jul 2006, at 15:04, Joel Guillod wrote:
For image processing I have to extract the RGB values from an
imagedata of an image but I got different results un
Is this an endian issue?
At 09:32 AM 7/25/2006, you wrote:
Joel ,
I don't know it's related, but I remember that, when building an external in C
for image processing, I found that the RGB values of each pixel was in a
different order on Mac and on Win. Therefore I had to swap the 3 values on
Joel ,
I don't know it's related, but I remember that, when building an external in C
for image processing, I found that the RGB values of each pixel was in a
different order on Mac and on Win. Therefore I had to swap the 3 values on
Win to get the correct order in Rev (actually MC)... I don't r
For image processing I have to extract the RGB values from an
imagedata of an image but I got different results under MacOSX and
Win32.
I found that the imagedata values is different between the two
platform: every color component of pixels is slighty changed. I have
not found in the docume
12 matches
Mail list logo
