Gradients (Revisited)
jjames
Posts: 2,908
Okay, so I might be beating a dead horse, but I'm ticked now. The TP data sheets clearly state that they are 18-bit screens. I tried loading an 8-bit PNG, and a 16-bit PNG - yet they still are very choppy. What is the panel doing? And does anyone know why you cannot import other 16-bit capable formats such as TARGA and PCT? The TPD4 help file says it converts everything into a JPG (unless it is a PNG) because of compression reasons. Or is it because these panels can only support PNGs and JPGs?
I've tried all sorts of manipulations to JPGs and PNGs trying to smooth it out and still get an UNACCEPTABLE gradient. This problem in whole truely is unacceptable. Attached is the TP file I'm using; could someone (or two) verify that they look terrible? THE GRADIENT ONLY USES 144 COLORS!!
It would be very nice for these panels to start accepting JPG2000 - which supports 16-bit depth - but I see this happening right next to the NetLinx language parsing XML.
I've tried all sorts of manipulations to JPGs and PNGs trying to smooth it out and still get an UNACCEPTABLE gradient. This problem in whole truely is unacceptable. Attached is the TP file I'm using; could someone (or two) verify that they look terrible? THE GRADIENT ONLY USES 144 COLORS!!
It would be very nice for these panels to start accepting JPG2000 - which supports 16-bit depth - but I see this happening right next to the NetLinx language parsing XML.
0
Comments
How will it look if the png is saved and used as 24bit png (although it has only 144 real colors)?
Can't help you here, but I figure the panel or TP4 is doing all sorts of things to try and sort colors out. I don't have the sw here and apparently some files are missing anyway, but have you tried just the gradient PNG, with nothing else (something else that would lead the software to try and maybe fail to optimize the whole lot)?
I don't fully see what you hope by that. The TFT is 18-bit per pixel. JPEG is 8-bit per color, so 24-bit per pixel total. You already are above what the TFT can show (the 262000) colors and its choppy. So what good is going to come from being able to import and store 48-bits per pixel files and then chop 30 bits out of them?
Because of its web abilities, the panel natively understands JPG and PNG (and GIF, supposedly). TPD4 probably allows importing other formats, but not all of them. It's not Photoshop or Corel Draw. TARGA and PCT are common, but not the most common formats today. I am also unsure they are compressed formats.
I guess AMX decided it would support importing only the most common formats.
My two cents
Fred
Saving a png file as 16-bit/8-bit, the colour pallette used will usually be optimised for the specific picture and colours within it.
From your example gradient the panels seem to have roughly 25 shades of blue in its internal pallette between the starting and ending blue colours(Got just by counting the number of bars when its displayed on the TP). No matter what you do to your image the touch panel will not be able to display any more shades of blue between your two colours as its pallette cannot be changed.
Saving as a 16-bit png does not help as the pallette saved with it would most likely be blue weighted(extra bits given to blues and hence extra shades). The touch panel wont be able to display any of these extra shades.
I've attached two images. One is the image input to the panel and one the displayed image. It has your gradient as a background, a 25 pixel wide gradient(Very smooth as every pixel is a different shade), a 50 pixel gradient(bars very barely visable if you look real close-every second pixel is a new shade), a 250 pixel gradient(bars quite visible now-10 pixel wide bars), and a 400 pixel gradient(Bars really visible now). In each case there will be 25 bars.
The gradient on the bottom of the image is a 25-pixel gradient scaled to 800 with no scaling algorithm(except pixel doubling). The bars in it match almost perfectly to the bars in the background.
The colours in images will always be mapped to the shades available in the touch panels internal pallette. If there arent enough shades in the pallette to display your gradient smoothly no amount of image manipulation will make it display correctly.
I surely don't claim to be the smartest person on the planet, or even know the most about color depths. I'll have to read up on all that so when I rant and rave about something not working, I can sound somewhat intelligent.
As far as not having the image in the TPD4 I attached in a previous post - that seems to be one of those screwy situations where you can't delete or import that image again.
I'll try to come up with a more organized (and working) TP sometime today.
Thanks for that test. The strange thing is, according to Fireworks 8, is that gradient supposedly only have 144 shades of blue. See attached image.
I'm not disputing that. The point is that those 144 shades will have to be rounded up or down to the closest shade that is in the touch panels internal palette which, as far as i can tell, only has 25 of the blue shades available in your fieworks palette. Therefore any shade in the fireworks palette without a direct match in the touch panel palette will be changed to the closest shade/colour available. In the end there will only be about 25 shades in you gradient when displayed.
There could be only 50 shades in your fireworks palette it would still only be displayed with 25 shades on the touch panel.
Well, that really inhales. Do you think this palette is in the firmware or do you think it's a hardware issue?
A little more testing shows that you obviously cannot from from a dark to light color. Attached are gradients that look decent on an MVP-8400. I'd be interested to see the results on a 15" or 17" since they have a 24-bit color depth.
I would assume fading from a dark to light color (like my first gradients) would look fine. Anyone here able to test?
Sorry if it sounded insulting or something. That was not my intention. I was just trying to explain how I understood things worked since maybe *I* was the one missing something :-)
I think what is happening is, even though the image uses a 144 color palette, and even though maybe the png is saved with the embedded palette (as GIFs are), the panel is chopping off 2 bits of every color in your image. That's the standard way to do 18 bit color, not use a palette. I mean, for the blue color, you probably go from xxxxx1xx to xxxxx0xx. The panel is removing the last 2 bits (sounds like a reasonable approach to approximately render all colors in an average image), so all xxxxx1xx (xxxxx111, xxxxx110, xxxxx101, etc...) are rendered as xxxxx1, and likewise for xxxxx0xx. One color is used to represent up to 4 in your gradient.
144/4 is about 35. We're still short of 10 colors... But besides the bit chopping, there may be other things happening in the display controller to adjust for gamma differences between PC and panel and this floating point operation done in integer has a tendency to have rouding errors...
What would be needed is some software that could work on 6 bits colors (even though it could save it as 8 bit PNG). You could be closer to WYSIWYG.
Hope this helps
Fred