A bug & note on using .png graphics
> OK, be prepared to be surprised. Pull down the Image menu, go to Mode and > gaze at the two entries "8 Bits / Channel" and "16 Bits / Channel." > I've been using it for years; it ain't new. > Yes, the Wikipedia article seems to verify what I was saying; that the same > file can be referred to a 8-bit or 24-bit and both terms can be correct, > depending on how you apportion the bits. I think the key here is one has to indicate, for clarity sake, that the reference is to "per channel"--but then, to be precise, one should indicate how many channels are involved and what color mode. There is a reference in the Photoshop help file: In most cases, Lab, RGB, grayscale, and CMYK images contain 8 bits of data per color channel. This translates to a 24?bit Lab bit depth (8 bits x 3 channels), a 24?bit RGB bit depth (8 bits x 3 channels), an 8?bit grayscale bit depth (8 bits x 1 channel), and a 32?bit CMYK bit depth (8 bits x 4 channels). Photoshop can also work with Lab, RGB, CMYK, multichannel, and grayscale images that contain 16 bits of data per color channel. Additionally, Photoshop can work with RGB and grayscale images that contain 32 bits of data per color channel. > http://www.luminous-landscape.com/tutorials/bit-depth.shtml, among > other industry sources ... I think the reference to RGB and printing is just some poor editing/writing--I don't think the writer was actually saying printers print in RGB. Since the website is photography-based (rather than commercial printing), inkjet printers are often thought of as RGB printers because they like to get their data in RGB and then convert to CMYK (or CcMmYKk, CMYKOG, etc.). As an aside, one only needs about 200 shades of gray to get a decent photo from commercial printing. It is the line screen (LPI), the resolution of the output device (DPI), and the resolution of the image (PPI) that are critical. Again, I think the website was dealing with photograph printing. David Creamer I.D.E.A.S. - Results-Oriented Training http://www.IDEAStraining.com Adobe Certified (since 1995) for ALL Print and Web Publishing-related software Authorized Quark Provider (since 1988) Markzware, Enfocus, FileMaker Certified Apple Certified Consultant (since 1990)
RE: A bug note on using .png graphics....
Art Campbell wrote: I think we're using slightly different terms when describing the same files. In photos/photoshop, an 8-bit depth means 8 bits of red, green, and blue info. 16 million shades (256X256X256). Which snip The color definition thing is really wierd. I never saw that happen before. Odd that it only seems to be png. I can see it being useful though if you have to color-match something in a layout to a graphic color, but it's still really odd that it'd pop up here. And it'd certainly add to file bloat. Makes me wonder if the crash was happening because the number of colors exceeded a maximum number in the file Like I said, I'm no expert, but I've never heard the term 8-bit used to describe an image that uses 24 bits to define each pixel, and I'd be very surprised if Photoshop uses the term that way. Color depth is generally specified as bits per pixel (bpp) -- see this Wikipedia topic: http://en.wikipedia.org/wiki/Color_depth It describes indexed color of various bit depths, including: 8-bit color (2^8 = 256 colors) VGA at low resolution, Super VGA And it contains this Truecolor definition: 24-bit Truecolor uses 8 bits to represent red, 8 bits to represent blue, and 8 bits to represent green. 2^8 = 256 levels of each of these three colors can therefore be combined to give a total of 16,777,216 mixed colors (256 x 256 x 256). As for the RGB color definitions, I'm confused as to whether your files have them or not. Do you see hundreds of color definitions of the form RGB 000, 082, 044? If so, there are (or were) palettized 256-color PNG graphics in the FM doc. AFAIK, that's the only place from which they can come. If all your PNGs are/were 16-million-color files, you shouldn't have hundreds of defined RGB colors in the doc. Richard -- Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 -- rgcombs AT gmailDOTcom 303-777-0436 -- ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: A bug note on using .png graphics....
Commenting only on specific issues... Art Campbell [EMAIL PROTECTED] wrote (in part): Color depth is generally specified as bits per pixel (bpp) -- see this Wikipedia topic: http://en.wikipedia.org/wiki/Color_depth snip Yes, the Wikipedia article seems to verify what I was saying; that the same file can be referred to a 8-bit or 24-bit and both terms can be correct, depending on how you apportion the bits. I disagree. Whenever the Wikipedia article refers to images or colors, it refers to the total number of bits per pixel. The only times it uses the terminology you favor it *always* refers to bits per channel. And one of the reason why PhotoShop uses the bits per channel in its menus is that it can deal with either RGB (3 channels per pixel) or CMYK (4 channels per pixel) color spaces. http://www.luminous-landscape.com/tutorials/bit-depth.shtml, among other industry sources ... If this website is one of the places you have been learning from, then perhaps we have identified the root source of some of the issues. Even on a quick reading, this page contains some things that are laughably inaccurate. For one example: A Short Digression This is why you don't want (for example) to print a BW image on an inkjet printer using just black ink. The printer would only be able to lay down 256 shades of gray, from black to white not nearly enough for a decent image. Instead you should print using colour inks as well, which means that all three primary colours (Red, Blue and Green) will be mixed together to create 16 million shades of gray (256X256X256). More than enough. Even if printers *did* print gray using red, blue, and green inks (which is not the case), 8-bit per channel color depth is still only capable of producing 256 shades of gray, *NOT* 16 million. The reason for this is simple: only colors where R=G=B are (nominally) gray, and there are only 256 such triplets. If any of the color intensities is not equal to the others, you get some color other than gray. 16 million shades of gray is simply an absurd concept. My opinions only; I don't speak for Intel. Fred Ridder Intel Parsippany, NJ _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: A bug note on using .png graphics....
Fred Ridder wrote: If this website is one of the places you have been learning from, then perhaps we have identified the root source of some of the issues. Even on a quick reading, this page contains some things that are laughably inaccurate. For one example: snip Wow. An inkjet printer with red, green, and blue ink. Producing 16 million shades of gray. I thought _my_ knowledge of color images was limited. That's the funniest thing I've read in a long time. Thanks, Fred! Art, good luck with your PNGs. :-) Richard -- Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 -- rgcombs AT gmailDOTcom 303-777-0436 -- ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
A bug & note on using .png graphics....
Art Campbell wrote: > I think we're using slightly different terms when describing > the same files. > In photos/photoshop, an 8-bit depth means 8 bits of red, > green, and blue info. 16 million shades (256X256X256). Which > The color definition thing is really wierd. I never saw that > happen before. > Odd that it only seems to be png. I can see it being useful > though if you have to color-match something in a layout to a > graphic color, but it's still really odd that it'd pop up > here. And it'd certainly add to file bloat. > > Makes me wonder if the crash was happening because the number > of colors exceeded a maximum number in the file Like I said, I'm no expert, but I've never heard the term "8-bit" used to describe an image that uses 24 bits to define each pixel, and I'd be very surprised if Photoshop uses the term that way. Color depth is generally specified as "bits per pixel (bpp)" -- see this Wikipedia topic: http://en.wikipedia.org/wiki/Color_depth It describes indexed color of various bit depths, including: "8-bit color (2^8 = 256 colors) VGA at low resolution, Super VGA" And it contains this Truecolor definition: "24-bit Truecolor uses 8 bits to represent red, 8 bits to represent blue, and 8 bits to represent green. 2^8 = 256 levels of each of these three colors can therefore be combined to give a total of 16,777,216 mixed colors (256 x 256 x 256)." As for the RGB color definitions, I'm confused as to whether your files have them or not. Do you see hundreds of color definitions of the form "RGB 000, 082, 044"? If so, there are (or were) palettized 256-color PNG graphics in the FM doc. AFAIK, that's the only place from which they can come. If all your PNGs are/were 16-million-color files, you shouldn't have hundreds of defined RGB colors in the doc. Richard -- Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 -- rgcombs AT gmailDOTcom 303-777-0436 --
A bug & note on using .png graphics....
Stuff cut in below... On 5/5/06, Combs, Richard wrote: > Like I said, I'm no expert, but I've never heard the term "8-bit" used > to describe an image that uses 24 bits to define each pixel, and I'd be > very surprised if Photoshop uses the term that way. OK, be prepared to be surprised. Pull down the Image menu, go to Mode and gaze at the two entries "8 Bits / Channel" and "16 Bits / Channel." I've been using it for years; it ain't new. Of course, Adobe may not be paying attention to wikipedia's bloggers. > Color depth is generally specified as "bits per pixel (bpp)" -- see this > Wikipedia topic: > > http://en.wikipedia.org/wiki/Color_depth Yes, the Wikipedia article seems to verify what I was saying; that the same file can be referred to a 8-bit or 24-bit and both terms can be correct, depending on how you apportion the bits. http://www.luminous-landscape.com/tutorials/bit-depth.shtml, among other industry sources ... > As for the RGB color definitions, I'm confused as to whether your files > have them or not. Do you see hundreds of color definitions of the form > "RGB 000, 082, 044"? If so, there are (or were) palettized 256-color PNG > graphics in the FM doc. AFAIK, that's the only place from which they can > come. Yes, it is confusing. The short answer is no and yes. No, the problem files I was referring to in the original message DO NOT have the color definitions (working in 7.2). The slightly more complex answer is that after I read the explanation online last night, I did a quick import of a .png on my home machine, and yes, there they were (in 7.1). > > If all your PNGs are/were 16-million-color files, you shouldn't have > hundreds of defined RGB colors in the doc. I agree. Cheers, Art -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358
A bug & note on using .png graphics....
Commenting only on specific issues... >Art Campbell wrote (in part): >>Color depth is generally specified as "bits per pixel (bpp)" -- see this >>Wikipedia topic: >> >>http://en.wikipedia.org/wiki/Color_depth > > >Yes, the Wikipedia article seems to verify what I was saying; that the same >file >can be referred to a 8-bit or 24-bit and both terms can be correct, >depending on how you >apportion the bits. I disagree. Whenever the Wikipedia article refers to images or colors, it refers to the total number of bits per pixel. The only times it uses the terminology you favor it *always* refers to "bits per channel". And one of the reason why PhotoShop uses the bits per channel in its menus is that it can deal with either RGB (3 channels per pixel) or CMYK (4 channels per pixel) color spaces. >http://www.luminous-landscape.com/tutorials/bit-depth.shtml, among >other industry sources ... If this website is one of the places you have been learning from, then perhaps we have identified the root source of some of the issues. Even on a quick reading, this page contains some things that are laughably inaccurate. For one example: A Short Digression This is why you don't want (for example) to print a B image on an inkjet printer using just black ink. The printer would only be able to lay down 256 shades of gray, from black to white ? not nearly enough for a decent image. Instead you should print using colour inks as well, which means that all three primary colours (Red, Blue and Green) will be mixed together to create 16 million shades of gray (256X256X256). More than enough. Even if printers *did* print gray using red, blue, and green inks (which is not the case), 8-bit per channel color depth is still only capable of producing 256 shades of gray, *NOT* 16 million. The reason for this is simple: only colors where R=G=B are (nominally) gray, and there are only 256 such triplets. If any of the color intensities is not equal to the others, you get some color other than gray. "16 million shades of gray" is simply an absurd concept. My opinions only; I don't speak for Intel. Fred Ridder Intel Parsippany, NJ _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
A bug & note on using .png graphics....
Fred Ridder wrote: > If this website is one of the places you have been learning > from, then perhaps we have identified the root source of some > of the issues. Even on a quick reading, this page contains > some things that are laughably inaccurate. For one example: Wow. An inkjet printer with red, green, and blue ink. Producing 16 million shades of gray. I thought _my_ knowledge of color images was limited. That's the funniest thing I've read in a long time. Thanks, Fred! Art, good luck with your PNGs. :-) Richard -- Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 -- rgcombs AT gmailDOTcom 303-777-0436 --
RE: A bug note on using .png graphics....
The only problem with that is that if they are less than 24-bit, FM adds all the colors in them to your colors list. :( After taking them down to 8 and saving them, you could probably take them back up to 24 with out making them too much bigger. Grant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Art Campbell Sent: Tuesday, May 02, 2006 2:09 PM To: List, Framers; Free Framers Subject: A bug note on using .png graphics I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the Gray Box warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell [EMAIL PROTECTED] ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: A bug note on using .png graphics....
Color list? You mean like FM's defined colors? I don't think so. We're talking digital photographs here, with millions of colors. The 8-bit limitation is just the bit depth of the file. FM doesn't do anything at all with the colors of graphics and the colors it defines it's a graphic file format attribute. Art On 5/4/06, Grant Hogarth [EMAIL PROTECTED] wrote: The only problem with that is that if they are less than 24-bit, FM adds all the colors in them to your colors list. :( After taking them down to 8 and saving them, you could probably take them back up to 24 with out making them too much bigger. Grant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Art Campbell Sent: Tuesday, May 02, 2006 2:09 PM To: List, Framers; Free Framers Subject: A bug note on using .png graphics I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the Gray Box warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell [EMAIL PROTECTED] -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: A bug note on using .png graphics....
Sadly, FM reads the color list from pngs (and AFAIK, *only* pngs), and adds the color definitions in the image file to the list of available colors in the FM file. It's very annoying. -Original Message- From: Art Campbell [mailto:[EMAIL PROTECTED] Sent: Thursday, May 04, 2006 1:57 PM To: Grant Hogarth Cc: List, Framers; Free Framers Subject: Re: A bug note on using .png graphics Color list? You mean like FM's defined colors? I don't think so. We're talking digital photographs here, with millions of colors. The 8-bit limitation is just the bit depth of the file. FM doesn't do anything at all with the colors of graphics and the colors it defines it's a graphic file format attribute. Art On 5/4/06, Grant Hogarth [EMAIL PROTECTED] wrote: The only problem with that is that if they are less than 24-bit, FM adds all the colors in them to your colors list. :( After taking them down to 8 and saving them, you could probably take them back up to 24 with out making them too much bigger. Grant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Art Campbell Sent: Tuesday, May 02, 2006 2:09 PM To: List, Framers; Free Framers Subject: A bug note on using .png graphics I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the Gray Box warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell [EMAIL PROTECTED] ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: A bug note on using .png graphics....
Annoying, yet brilliantly exacting. ;-) On 5/4/06, Grant Hogarth [EMAIL PROTECTED] wrote: Sadly, FM reads the color list from pngs (and AFAIK, *only* pngs), and adds the color definitions in the image file to the list of available colors in the FM file. It's very annoying. -- Bill Swallow HATT List Owner WWP-Users List Owner Senior Member STC, TechValley Chapter http://techcommdood.blogspot.com ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: A bug note on using .png graphics....
Sadly, FM reads the color list from pngs (and AFAIK, *only* pngs), and adds the color definitions in the image file to the list of available colors in the FM file. It's very annoying. And don't forget that you can't delete them with the color definition thing where you can delete every other color! Anne The information contained in or attached to this e-mail contains confidential or privileged information. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is PROHIBITED. If you have received this e-mail in error, please notify the sender and delete the e-mail immediately. Thank you. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: A bug note on using .png graphics....
16 million colors vs 256 for GIF --- Jim Light [EMAIL PROTECTED] wrote: So someone refresh my memory please, the advantage of using png files is what? John Posada Senior Technical Writer So long and thanks for all the fish. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: A bug note on using .png graphics....
I think we're using slightly different terms when describing the same files. In photos/photoshop, an 8-bit depth means 8 bits of red, green, and blue info. 16 million shades (256X256X256). Which is what I think you're calling 24 bit, meaning 3x8 bits. Files come out of my Nikons at 12-bit depth and are treated in Photoshop as 16-bit, which means millions more possible colors. Interpolated means resized or having the resolution adjusted in such a way that the software supplies missing pixel data when necessary. When pixels have to be dropped when an image shrinks or added when it is enlarged, an interpolation routine is at work. 300 dpi for offset press work isn't excessive. The color definition thing is really wierd. I never saw that happen before. Odd that it only seems to be png. I can see it being useful though if you have to color-match something in a layout to a graphic color, but it's still really odd that it'd pop up here. And it'd certainly add to file bloat. Makes me wonder if the crash was happening because the number of colors exceeded a maximum number in the file Art On 5/4/06, Combs, Richard [EMAIL PROTECTED] wrote: Art Campbell wrote: Color list? You mean like FM's defined colors? I don't think so. We're talking digital photographs here, with millions of colors. The 8-bit limitation is just the bit depth of the file. FM doesn't do anything at all with the colors of graphics and the colors it defines it's a graphic file format attribute. Nope, not millions of colors -- millions of _possible_ colors. But each 8-bit graphic contains only 2^8, or 256, unique colors -- a palette of 256 defined RGB colors, all of which are added to your FM color list like this: RGB 000, 000, 136 RGB 000, 082, 044 RGB 056, 188, 000 So Grant is right. Since each new 8-bit PNG contains its own palette of 256 unique colors, you can end up with hundreds -- even thousands -- of new colors in your FM doc. Go ahead, select View Color Definitions, and then look at the Name list. Since your graphics started life as photos, I'm surprised that the 256-color limit isn't a problem, but then I don't know what they're pictures of. I don't understand your original crash problem, or how the photos ended up being 16-bit color (are you sure?), or what interpolated to size means. But you might try saving them as 24-bit color, which is more standard. You might also try significantly reducing the dpi. I'm no expert, but 300 dpi for a photo seems excessive. IIRC, after you remove the 8-bit PNGs, saving the doc as MIF will get rid of all the RGB color definitions. Richard -- Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 -- rgcombs AT gmailDOTcom 303-777-0436 -- -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
A bug & note on using .png graphics....
The only problem with that is that if they are less than 24-bit, FM adds all the colors in them to your colors list. :( After taking them down to 8 and saving them, you could probably take them back up to 24 with out making them too much bigger. Grant -Original Message- From: framers-bounces+grant.hogarth=reuters@lists.frameusers.com [mailto:framers-bounces+grant.hogarth=reuters.com at lists.frameusers.com] On Behalf Of Art Campbell Sent: Tuesday, May 02, 2006 2:09 PM To: List, Framers; Free Framers Subject: A bug & note on using .png graphics I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the "Gray Box" warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell art.campbell at gmail.com
A bug & note on using .png graphics....
Sadly, FM "reads" the color list from pngs (and AFAIK, *only* pngs), and adds the color definitions in the image file to the list of available colors in the FM file. It's very annoying. -Original Message- From: Art Campbell [mailto:art.campb...@gmail.com] Sent: Thursday, May 04, 2006 1:57 PM To: Grant Hogarth Cc: List, Framers; Free Framers Subject: Re: A bug & note on using .png graphics Color list? You mean like FM's defined colors? I don't think so. We're talking digital photographs here, with millions of colors. The 8-bit limitation is just the bit depth of the file. FM doesn't do anything at all with the colors of graphics and the colors it defines it's a graphic file format attribute. Art On 5/4/06, Grant Hogarth wrote: > The only problem with that is that if they are less than 24-bit, FM > adds all the colors in them to your colors list. :( After taking them > down to 8 and saving them, you could probably take them back up to 24 > with out making them too much bigger. > > Grant > > -Original Message- > From: framers-bounces+grant.hogarth=reuters.com at lists.frameusers.com > [mailto:framers-bounces+grant.hogarth=reuters.com at lists.frameusers.com > ] > On Behalf Of Art Campbell > Sent: Tuesday, May 02, 2006 2:09 PM > To: List, Framers; Free Framers > Subject: A bug & note on using .png graphics > > I recently ran into a problem using .png graphics in files and after > kicking it around a lot, think I may have found a bug either in FM's > memory managment > (surprise!) or the > way it's handling graphics files. > > * FM 7.2 / 158 > * Windows XP SP2 with all patches > * Two machines, one with 2 M RAM, one with 3 > * FM files and graphics on a network server > > The symptoms were: > * Importing .png files by reference > * FM would occasionally display the "Gray Box" warning message > * It would always crash > > It turned out the graphics I was using were big files that started > life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to > size, and were saved out as 300 dpi .png files for import. > > The details are important, it turns out, because the files retained a > 16-bit color depth throughout. And that seems to be the thing that > tripped FM up. > > On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop > and resaved them and voila -- no crashes, no gray boxes, nothing at > all untoward. > > I haven't tested this with other formats to see if the bit-depth is an > issue with other file formats, but I wouldn't be surprised if it were. > > Cheers, > Art > > -- > Art Campbell > art.campbell at gmail.com
A bug & note on using .png graphics....
Annoying, yet brilliantly exacting. ;-) On 5/4/06, Grant Hogarth wrote: > Sadly, FM "reads" the color list from pngs (and AFAIK, *only* pngs), and > adds the color definitions in the image file to the list of available > colors in the FM file. It's very annoying. -- Bill Swallow HATT List Owner WWP-Users List Owner Senior Member STC, TechValley Chapter http://techcommdood.blogspot.com
A bug & note on using .png graphics....
> Sadly, FM "reads" the color list from pngs (and AFAIK, *only* > pngs), and adds the color definitions in the image file to > the list of available colors in the FM file. It's very annoying. And don't forget that you can't delete them with the color definition thing where you can delete every other color! Anne The information contained in or attached to this e-mail contains confidential or privileged information. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is PROHIBITED. If you have received this e-mail in error, please notify the sender and delete the e-mail immediately. Thank you.
A bug & note on using .png graphics....
So someone refresh my memory please, the advantage of using png files is what? -Original Message- From: framers-bounces+jlight=pillardata@lists.frameusers.com [mailto:framers-bounces+jlight=pillardata.com at lists.frameusers.com] On Behalf Of Anne Robotti Sent: Thursday, May 04, 2006 1:41 PM To: Grant Hogarth; framers at lists.frameusers.com Subject: RE: A bug & note on using .png graphics > Sadly, FM "reads" the color list from pngs (and AFAIK, *only* > pngs), and adds the color definitions in the image file to > the list of available colors in the FM file. It's very annoying. And don't forget that you can't delete them with the color definition thing where you can delete every other color! Anne The information contained in or attached to this e-mail contains confidential or privileged information. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is PROHIBITED. If you have received this e-mail in error, please notify the sender and delete the e-mail immediately. Thank you. ___ You are currently subscribed to Framers as jlight at pillardata.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/jlight%40pillardata. com Send administrative questions to lisa at frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
A bug & note on using .png graphics....
16 million colors vs 256 for GIF --- Jim Light wrote: > So someone refresh my memory please, the advantage of using png > files is what? > John Posada Senior Technical Writer "So long and thanks for all the fish."
A bug & note on using .png graphics....
Art Campbell wrote: > Color list? You mean like FM's defined colors? > I don't think so. We're talking digital photographs here, > with millions of colors. > The 8-bit limitation is just the bit depth of the file. FM > doesn't do anything at all with the colors of graphics and > the colors it defines it's a graphic file format attribute. Nope, not millions of colors -- millions of _possible_ colors. But each 8-bit graphic contains only 2^8, or 256, unique colors -- a palette of 256 defined RGB colors, all of which are added to your FM color list like this: RGB 000, 000, 136 RGB 000, 082, 044 RGB 056, 188, 000 So Grant is right. Since each new 8-bit PNG contains its own palette of 256 unique colors, you can end up with hundreds -- even thousands -- of new colors in your FM doc. Go ahead, select View > Color > Definitions, and then look at the Name list. Since your graphics started life as photos, I'm surprised that the 256-color limit isn't a problem, but then I don't know what they're pictures of. I don't understand your original crash problem, or how the photos ended up being 16-bit color (are you sure?), or what "interpolated to size" means. But you might try saving them as 24-bit color, which is more standard. You might also try significantly reducing the dpi. I'm no expert, but 300 dpi for a photo seems excessive. IIRC, after you remove the 8-bit PNGs, saving the doc as MIF will get rid of all the RGB color definitions. Richard -- Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 -- rgcombs AT gmailDOTcom 303-777-0436 --
A bug & note on using .png graphics....
I think we're using slightly different terms when describing the same files. In photos/photoshop, an 8-bit depth means 8 bits of red, green, and blue info. 16 million shades (256X256X256). Which is what I think you're calling 24 bit, meaning 3x8 bits. Files come out of my Nikons at 12-bit depth and are treated in Photoshop as 16-bit, which means millions more possible colors. Interpolated means resized or having the resolution adjusted in such a way that the software supplies missing pixel data when necessary. When pixels have to be dropped when an image shrinks or added when it is enlarged, an interpolation routine is at work. 300 dpi for offset press work isn't excessive. The color definition thing is really wierd. I never saw that happen before. Odd that it only seems to be png. I can see it being useful though if you have to color-match something in a layout to a graphic color, but it's still really odd that it'd pop up here. And it'd certainly add to file bloat. Makes me wonder if the crash was happening because the number of colors exceeded a maximum number in the file Art On 5/4/06, Combs, Richard wrote: > Art Campbell wrote: > > > Color list? You mean like FM's defined colors? > > I don't think so. We're talking digital photographs here, > > with millions of colors. > > The 8-bit limitation is just the bit depth of the file. FM > > doesn't do anything at all with the colors of graphics and > > the colors it defines it's a graphic file format attribute. > > Nope, not millions of colors -- millions of _possible_ colors. But each > 8-bit graphic contains only 2^8, or 256, unique colors -- a palette of > 256 defined RGB colors, all of which are added to your FM color list > like this: > > RGB 000, 000, 136 > RGB 000, 082, 044 > RGB 056, 188, 000 > > So Grant is right. Since each new 8-bit PNG contains its own palette of > 256 unique colors, you can end up with hundreds -- even thousands -- of > new colors in your FM doc. Go ahead, select View > Color > Definitions, > and then look at the Name list. > > Since your graphics started life as photos, I'm surprised that the > 256-color limit isn't a problem, but then I don't know what they're > pictures of. I don't understand your original crash problem, or how the > photos ended up being 16-bit color (are you sure?), or what > "interpolated to size" means. But you might try saving them as 24-bit > color, which is more standard. You might also try significantly reducing > the dpi. I'm no expert, but 300 dpi for a photo seems excessive. > > IIRC, after you remove the 8-bit PNGs, saving the doc as MIF will get > rid of all the RGB color definitions. > > Richard > > > -- > Richard G. Combs > Senior Technical Writer > Polycom, Inc. > richardDOTcombs AT polycomDOTcom > 303-223-5111 > -- > rgcombs AT gmailDOTcom > 303-777-0436 > -- > > > > > -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358
A bug note on using .png graphics....
I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the Gray Box warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: A bug note on using .png graphics....
Glad to possibly help you Art! I had trouble with FrameMaker freezing and crashing while using Snagit 8.0. Was using save Web URLs and scroll bar for the captured windows. Updated to Snagit 8.01. Used .jpg instead of .png. Works ok in Frame 7.2. When saving these images, get a message to save without the URLs. Can't use scroll bar which is nice to take multiple pictures. Here is admission of trouble from Techsmith: Discussion Thread Response (Melissa G.) 04/25/2006 09:10 AM Nandini, are you using the FrameMaker 7.2 add-in for SnagIt? If so, we have been running into problems with this. SnagIt is currently being tested in our internal testing department for these compatibility issues (and a resolution). You can try, for now, to run SnagIt from the system tray and then pressing PrintScreen when you need to take a capture. Also, make sure your notifications are turned off under tools program preferences notification. Uncheck show all tips and show all balloon tips. Click apply ok to close the window. Nandini Frankly, I am going to switch to 7.0 if the problems persist. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Art Campbell Sent: Tuesday, May 02, 2006 1:09 PM To: List, Framers; Free Framers Subject: A bug note on using .png graphics I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the Gray Box warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: A bug note on using .png graphics....
Nandini, I am running SnagIt 8.01, but I never enabled the add-in; I always run it as a free-standing program and haven't had any problems (even saving as .png -- they write out 8 bits). Cheers, Art On 5/2/06, Nandini Garud [EMAIL PROTECTED] wrote: Glad to possibly help you Art! I had trouble with FrameMaker freezing and crashing while using Snagit 8.0. Was using save Web URLs and scroll bar for the captured windows. Updated to Snagit 8.01. Used .jpg instead of .png. Works ok in Frame 7.2. When saving these images, get a message to save without the URLs. Can't use scroll bar which is nice to take multiple pictures. Here is admission of trouble from Techsmith: Discussion Thread Response (Melissa G.) 04/25/2006 09:10 AM Nandini, are you using the FrameMaker 7.2 add-in for SnagIt? If so, we have been running into problems with this. SnagIt is currently being tested in our internal testing department for these compatibility issues (and a resolution). You can try, for now, to run SnagIt from the system tray and then pressing PrintScreen when you need to take a capture. Also, make sure your notifications are turned off under tools program preferences notification. Uncheck show all tips and show all balloon tips. Click apply ok to close the window. Nandini Frankly, I am going to switch to 7.0 if the problems persist. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Art Campbell Sent: Tuesday, May 02, 2006 1:09 PM To: List, Framers; Free Framers Subject: A bug note on using .png graphics I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the Gray Box warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
A bug & note on using .png graphics....
I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the "Gray Box" warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358
A bug & note on using .png graphics....
Glad to possibly help you Art! I had trouble with FrameMaker freezing and crashing while using Snagit 8.0. Was using save Web URLs and scroll bar for the captured windows. Updated to Snagit 8.01. Used .jpg instead of .png. Works ok in Frame 7.2. When saving these images, get a message to save without the URLs. Can't use scroll bar which is nice to take multiple pictures. Here is admission of trouble from Techsmith: Discussion Thread Response (Melissa G.) 04/25/2006 09:10 AM Nandini, are you using the FrameMaker 7.2 add-in for SnagIt? If so, we have been running into problems with this. SnagIt is currently being tested in our internal testing department for these compatibility issues (and a resolution). You can try, for now, to run SnagIt from the system tray and then pressing PrintScreen when you need to take a capture. Also, make sure your notifications are turned off under tools > program preferences > notification. Uncheck show all tips and show all balloon tips. Click apply > ok to close the window. Nandini Frankly, I am going to switch to 7.0 if the problems persist. -Original Message- From: framers-bounces+nandini=resonate@lists.frameusers.com [mailto:framers-bounces+nandini=resonate.com at lists.frameusers.com]On Behalf Of Art Campbell Sent: Tuesday, May 02, 2006 1:09 PM To: List, Framers; Free Framers Subject: A bug & note on using .png graphics I recently ran into a problem using .png graphics in files and after kicking it around a lot, think I may have found a bug either in FM's memory managment (surprise!) or the way it's handling graphics files. * FM 7.2 / 158 * Windows XP SP2 with all patches * Two machines, one with 2 M RAM, one with 3 * FM files and graphics on a network server The symptoms were: * Importing .png files by reference * FM would occasionally display the "Gray Box" warning message * It would always crash It turned out the graphics I was using were big files that started life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to size, and were saved out as 300 dpi .png files for import. The details are important, it turns out, because the files retained a 16-bit color depth throughout. And that seems to be the thing that tripped FM up. On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop and resaved them and voila -- no crashes, no gray boxes, nothing at all untoward. I haven't tested this with other formats to see if the bit-depth is an issue with other file formats, but I wouldn't be surprised if it were. Cheers, Art -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358 ___
A bug & note on using .png graphics....
Nandini, I am running SnagIt 8.01, but I never enabled the add-in; I always run it as a free-standing program and haven't had any problems (even saving as .png -- they write out 8 bits). Cheers, Art On 5/2/06, Nandini Garud wrote: > Glad to possibly help you Art! > > I had trouble with FrameMaker freezing and crashing while using Snagit 8.0. > Was using save Web URLs and scroll bar for the captured windows. > > Updated to Snagit 8.01. Used .jpg instead of .png. Works ok in Frame 7.2. > When saving these images, get a message to save without the URLs. Can't use > scroll bar which is nice to take multiple pictures. > > Here is admission of trouble from Techsmith: > > Discussion Thread > Response (Melissa G.) > 04/25/2006 09:10 AM > Nandini, are you using the FrameMaker 7.2 add-in for SnagIt? If so, we have > been running into problems with this. SnagIt is currently being tested in > our internal testing department for these compatibility issues (and a > resolution). You can try, for now, to run SnagIt from the system tray and > then pressing PrintScreen when you need to take a capture. Also, make sure > your notifications are turned off under tools > program preferences > > notification. Uncheck show all tips and show all balloon tips. Click apply > > ok to close the window. > > Nandini > > Frankly, I am going to switch to 7.0 if the problems persist. > > -Original Message- > From: framers-bounces+nandini=resonate.com at lists.frameusers.com > [mailto:framers-bounces+nandini=resonate.com at lists.frameusers.com]On Behalf > Of Art Campbell > Sent: Tuesday, May 02, 2006 1:09 PM > To: List, Framers; Free Framers > Subject: A bug & note on using .png graphics > > I recently ran into a problem using .png graphics in files and after > kicking it around a > lot, think I may have found a bug either in FM's memory managment > (surprise!) or the > way it's handling graphics files. > > * FM 7.2 / 158 > * Windows XP SP2 with all patches > * Two machines, one with 2 M RAM, one with 3 > * FM files and graphics on a network server > > The symptoms were: > * Importing .png files by reference > * FM would occasionally display the "Gray Box" warning message > * It would always crash > > It turned out the graphics I was using were big files that started > life on Nikon DSLRs, were massaged in Photoshop CS2, interpolated to > size, and were saved out as 300 dpi .png files for import. > > The details are important, it turns out, because the files retained a > 16-bit color depth > throughout. And that seems to be the thing that tripped FM up. > > On a hunch, I knocked the .PNG files down to 8-bit depth in Photoshop > and resaved them and voila -- no crashes, no gray boxes, nothing at > all untoward. > > I haven't tested this with other formats to see if the bit-depth is an > issue with other file formats, but I wouldn't be surprised if it were. > > Cheers, > Art > > -- > Art Campbell > art.campbell at gmail.com > "... In my opinion, there's nothing in this world beats a '52 Vincent >and a redheaded girl." -- Richard Thompson > No disclaimers apply. > DoD 358 > ___ > > > > > > -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358
A bug & note on using .png graphics....
Something that doesn't throw away data. Snagit saves 8-bit .png which
works very nicely.
Art
On 5/2/06, Nandini Garud wrote:
> Thanks Fred. This is the option suggested by IT: .jpg. So, what would you
> choose? Having to edit it in Photoshop is not an option for me. I don't have
> it!
>
> Nandini
>
> -Original Message-
> From: Ridder, Fred [mailto:fred.ridder at intel.com]
> Sent: Tuesday, May 02, 2006 1:44 PM
> To: Nandini Garud; Art Campbell
> Subject: RE: A bug & note on using .png graphics
>
> JPEG is a very poor choice of file format for screen shots because it
> invariably produces artifacts ("smudginess") near text, lines, and
> other abrupt color transitions, which generally abound in screen shots.
> It is the only common file format that is subject to this kind of
> inherent
> degradation. JPEG was designed for *photographic* images where
> the number of abrupt transitions (edges) is relatively small and where
> the surface textures of the objects in the scene will mask the
> artifacts.
> Screen shots are *mostly* edges and there is nothing to conceal the
> artifacts.
--
Art Campbell art.campbell at
gmail.com
"... In my opinion, there's nothing in this world beats a '52 Vincent
and a redheaded girl." -- Richard Thompson
No disclaimers apply.
DoD 358
