If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#61
|
|||
|
|||
Image formats
"Paul" wrote
| But surely you look for a libpng, | before writing your own ? | | I'm not much of a programmer, but if a library | is available, I'll use it. I'm the opposite. I use conveniences when I can, where it doesn't matter. I love VB6 for that. It's very simple to get basic GUI controls with little work. But I like the efficiency and portability of avoiding wrappers. So for actual operations in the software I try to use straight code or Win32 API. Before GDI+ I used to use a small JPG library written in Delphi, and at that time PNG was virtually unknown. Now with GDI+ I can call that to handle JPG saving. And PNG still isn't very popular. I only wrote the code because I wanted it for my Explorer Bar. I actually adapted someone else's unfinished code. Awhile back I was talking to a friend who works in Java and said I liked to use direct Win32 API whenever possible. He said, "Oh, yeah, the old Win32". Most people think of it that way now. They've got .Net or Java wrapping Win32. Often there are even intermediate DLLs to simplify things. They don't understand that they're still using Win32 API. They think they have "a more modern tool". I think of it like cooking. There are numerous levels of brass tacks. If you want a pasta dinner you can order take-out and have it delivered. Or you can go pick it up. Or you can zap a frozen dinner. Or you can boil spaghetti and dump some bottled Ragu on top. Or you can add some oregano and onions to the Ragu for "customization". Or you can make your own sauce. You can even make your own pasta. And you could grow your own tomatoes. Perhaps even grow and grind your own wheat. I'm not a fanatic. I don't work in assembly. But I like to do my own cooking. It's more efficient, more flexible, and less costly. So I make my own sauce. And my software can run on virtually any Windows machine in use without needing support files. I've never even written a program much over 1 MB. Most software used to be like that. MS Office 95 installed from a pile of floppies. My PSP16 is probably about 5 times the size of PSP5 and labors to start up. It's got almost as much Python crap as the entire PSP5! Yet it only has slightly more functionality than PSP5. And the GUI is worse. So I only use 16 rarely. People used to make fun of the RAD simplicity of VB, yet now the former hardcore C++ people are using the C# or VB.Net wrapper -- a bloated, "for dummies" OO system. I've written my own code for many things. Winsock, http, smtp, cabinet.dll, graphics operations, NT permissions, color syntax highlighting in a RichEdit, typelib parsing, etc. Partly I like the challenge. But I also like to make it clean and know the code. And it's much more efficient that way. .Net software has to load gobs of DLLs just to start, then all calls go through a chain of wrappers. I'm mostly just calling the Win32 API directly, or using straight code operations, except for most GUI elements. It allows me to write exactly what I need and it's usually better than what's available. For instance, at one point I wanted a quick color syntax highlighter in VBScript, for an HTA, so I could paste obfuscated webpage script to read it more easily. I found the "open source" jsbeautifier. It was crap. I wrote a much better version in a few days. But everyone else was using jsbeautifier because it was the OSS standard. I suppose most things are like that. More and more specialization. Fewer and fewer people writing their own code, or doing their own oil changes, or cooking their own dinner... The other day I was at Home Depot looking for laminate (formica, etc) snips and discovered they no longer sell laminate, trimmers, glue, or snips. Laminate is now a specialty. The store for contractors and handymen is turning into an outlet to buy take-out spaghetti dinners. Though I can't really say I write all the code. I usually find sample code to get me started, for most things, as with the PNG parser. I also wrote VB code for turbojeg.dll, an OSS DLL. I wanted to be able to display JPG tumbnails quickly. The quickest way is to just extract it from the file. But not all JPGs have an embedded thumbnail. And some can be very big. After a lot of research I found that turbojpeg seemed to offer the fastest possible JPG parsing to get a thumbnail out of a giant image. It's very fast at making reduced size images of high quality. But for basic operations GDI+ is fine. | The problem now, is a shortage of tools for images | with over 4 billion pixels :-) (Yeah, I only have | one file like that. It's 10GB or so. I'd show it | to you, but... the image hosting sites would not | like that.) | I hope that's a picture of your adorable baby. I'd rather think of you as a sentimentalist than as being entirely out to lunch. |
Ads |
#62
|
|||
|
|||
Image formats
"J. P. Gilliver (John)" wrote
| Even that's not totally unique (is this a rare case where that phrase | can be validlly used!): one of the other formats, GIF I think, has the | option of declaring one of its colours as the transparent one. (Come to | think of it, .ico must as well). I gather PNG has _degree_ of | transparency, which is different - the others have only yes or no. Yes, GIF can have one color transparent, which is convenient and easy to make use of. ICO has traditionally been a compound file, with one or more BMPs inside. Each BMP then has a 2-color mask bitmap as a key to which pixels should/shouldn't be painted. These days I think a Windows icon can be either an actual ICO or a PNG. I'm not sure how it works on newer systems. PNG transparency not only has degrees but also per-pixel. Each pixel in a 24-bit bitmap is 3 bytes of RGB. 0,0,0 is black. 255,255,255 is white. Same with JPG, which is just a compressed BMP with sophisticated methods applied to make it look good with less data. But once it's decompressed it's still just a grid of RGB values. PNG lets you set transparency through the "alpha channel", a fourth pixel. So the bytes of a PNG image makes it 1/3 bigger to start with. Each pixel needs 4 bytes of data. But you can do something like make every red pixel 255,0,0,128 to make red 50% transparent. Or you could make the image fade out at the edges. Or you could make some aspects solid and some transparent. The problem with that is it's very processor intensive to render it, and it's nearly impossible to make a tool to do it easily. Such a tool not only has to remember the alpha value for every pixel in an image, and recalculate when the image is changed, but it would also have to provide a convenient GUI for doing the operation. I could make an HTA to do things like fade the left side using wiaaut.dll. But making a usable GUI tool would be farfetched. Thus, PNG transparency is mostly used as a 24-bit GIF. An image with transparent background. So that's probably part of why PNG is still not popular. It's not really used for that aspect. It's only used for high quality 24-bit images that must be able to render on all machines. Like JPG, it's universally supported but has big drawbacks, like slow/complex and large file size. When you look at popular online sites you can see that most images are JPGs that have been reduced to a point where they're barely discernible at the displayed resolution. Enlarge that image a bit and you just see squares of color... Which is odd. They're loading 5 MB of script but cutting corners on a 50 KB JPG! So those sites are not going to switch to PNG. Even if they want transparency, that can be done with CSS, so there's very little to recommend PNG. Example: Save this code to an HTML file and replace IMG SRC, WIDTH, HEIGHT with the specs of an image in the same location. When you load the page you'll see a red-tinted image. The style setting specifies FF0000 background (red) and 50% opacity for the image. (Values go 0 to 1.0) |
#63
|
|||
|
|||
Image formats
Woops. Forgot the code:
HTMLHEAD STYLE body {background-color: #FF0000;} #Im1 {opacity: 0.5;} /STYLE /HEAD BODY IMG ID="Im1" SRC="heat.gif" WIDTH=919 HEIGHT=571 /BODY/HTML |
#64
|
|||
|
|||
[OT]Does the .png image format have a text metadata field?
"Mayayana" on Thu, 13 Feb 2020 19:05:04
-0500 typed in alt.windows7.general the following: "Shadow" wrote | Since almost all image formats are compressed, do you know a | tool that can un-compress the data to look for "hidden" text or files? | There's a lot of apps that do steganography, so there must be | something to identify the method used (a generic un-packer). | The NSA would be naked without one. LOL. | Mysterious. So it hides extra bytes? Since each format is different I don't know of any easy way to track it, or to create the hidden text. Not so much "hides" as substitutes not enough to be "noticeable" to "casual inspection." How many "bad pixels" can you have before the picture "fails" as an image. It is harder to do with written text, there isn't the redundancy. "But iF I leVitate eXtra aNdoids, vaRious eleCtrons traVel ovEr hill and daLe anD to yOrk." [First letter of each miscapitalized word.) I recall a movie where the message was smuggled out by writing over letters with a lead (metal) pencil. You had to X-ray the pages to read it, but, hey, it "worked". -- pyotr filipivich Next month's Panel: Graft - Boon or blessing? |
#65
|
|||
|
|||
[OT]Does the .png image format have a text metadata field?
"pyotr filipivich" wrote
| Not so much "hides" as substitutes not enough to be "noticeable" | to "casual inspection." How many "bad pixels" can you have before the | picture "fails" as an image. | Seems a bit farfetched. I suppose it might be OK in a large image, but when numerous pixels bear no resemblance to the contiguous pixels, that's an oddity. Hopefully they're not being used to send nuclear codes and only things like, "Don't forget mustard with the President's Happy Meal". |
#66
|
|||
|
|||
[OT]Does the .png image format have a text metadata field?
Mayayana wrote:
"pyotr filipivich" wrote | Not so much "hides" as substitutes not enough to be "noticeable" | to "casual inspection." How many "bad pixels" can you have before the | picture "fails" as an image. | Seems a bit farfetched. I suppose it might be OK in a large image, but when numerous pixels bear no resemblance to the contiguous pixels, that's an oddity. Hopefully they're not being used to send nuclear codes and only things like, "Don't forget mustard with the President's Happy Meal". You can see the dot density. https://en.wikipedia.org/wiki/Machin...ntermarkrp.jpg This one shows you the print mechanism is not bashful about it. They don't change the color of the dots to reduce visibility. https://www.heise.de/newsticker/meld...n-4090876.html You can read that in English, here. Kinda amusing. https://translate.google.com/transla...n-4090876.html "Timo and Stephan examined 1,286 printouts from 141 printers from 18 different manufacturers" I'm guessing they were bored at the time. That's a lot of yellow dots to stare at. I suppose next we'll see "and Timo and Stephan made $7 million using an ordinary inkjet printer" :-) Now, overreach, would be if that dot pattern was spotted on a *black and white* printer, where there is no chance of currency counterfeiting. This is their toolset - presumably to be used if you scan a color laser printer document, and want to anonymize it before re-printing on your own office printer. So the original document cannot be tracked to its printer. https://github.com/dfd-tud/deda Paul |
#67
|
|||
|
|||
[OT]Does the .png image format have a text metadata field?
Mayayana,
Seems a bit farfetched. Not really. I created a 640x480 24 bbp image, totally light blue (0x07F7FFF). Than I "hid" text in it in a single line of pixels. Even though I (ofcourse) knew where I placed that text I could not see it. I even went as far as to clear or set the lower /four/ bits of each color byte (thats 12 bits of data per pixel ), and still had something that was almost invisible. Than I did the same on an image of somes face. Even though I knew where it was, I could not find it anymore. And mind you, that was 12 databits per pixel. With one bit per color byte (three in total) it would be all but invisible. Hopefully they're not being used to send nuclear codes and only things like They might as well. There is a /lot/ you need to know about how the message is stored to be able to retrieve its bits, starting with /that/ you have to look, and than /where/. The message might start from any pixel. Also, the next data pixel might be in any of the eight directions, and not even directly next to the previous one. And the shorter the message, the easier it is to hide. And thats even assuming that the message itself is not first obscured as well ... (making it even harder to recognise patterns in the colors lower bits). Regards, Rudy Wieser |
#68
|
|||
|
|||
[OT]Does the .png image format have a text metadata field?
"Mayayana" on Sat, 15 Feb 2020 12:38:02
-0500 typed in alt.windows7.general the following: "pyotr filipivich" wrote | Not so much "hides" as substitutes not enough to be "noticeable" | to "casual inspection." How many "bad pixels" can you have before the | picture "fails" as an image. | Seems a bit farfetched. I suppose it might be OK in a large image, but when numerous pixels bear no resemblance to the contiguous pixels, that's an oddity. Yep. Whether that oddity is part of the cover, I don't know. "It all depends" As I said, embed they lyrics to "Harvey the wonder hamster." in the photograph, the spooks will find that, and miss the real message which is contained in the kitten being on the left side, looking to the right, at a daisy. Hopefully they're not being used to send nuclear codes and only things like, "Don't forget mustard with the President's Happy Meal". Embedding code words in a photograph doesn't have to be that verbose. And that's all it takes, is the code words. -- pyotr filipivich Next month's Panel: Graft - Boon or blessing? |
#69
|
|||
|
|||
[OT]Does the .png image format have a text metadata field?
On 15.02.20 18:38, Mayayana wrote:
"pyotr filipivich" wrote | Not so much "hides" as substitutes not enough to be "noticeable" | to "casual inspection." How many "bad pixels" can you have before the | picture "fails" as an image. | Seems a bit farfetched. I suppose it might be OK in a large image, but when numerous pixels bear no resemblance to the contiguous pixels, that's an oddity. Hopefully they're not being used to send nuclear codes and only things like, "Don't forget mustard with the President's Happy Meal". Very easy to avoid. Just use the lowest bit of each color byte, giving 3 bits for each pixel, and that would be enough, the lowest bits tend to be just noise anyway. Oops , is CIA listening??? |
#70
|
|||
|
|||
Image formats
On 15/02/2020 04:27, Mayayana wrote:
I use BMP or TIF for that. I could use PNG but it's relatively bloated and it's also complex. Try saving a big image as TIF and then PNG. PNG is a lot of work to pack and unpack. It's slow. And as I wrote to Java Jive, I did a test yesterday and found that PNGs are much bigger than TIFs. You might use BMP? Yet you go on to moan about large size of PNG? I don't notice any difference in speed between PNG and TIFF. You running an 8086? Also I just tested with a photo and the PNG was actually a little smaller than the TIFF suggesting that whenever you use to export to PNG isn't correctly optimising the compression. -- Brian Gregory (in England). |
#71
|
|||
|
|||
Image formats
On 17/02/2020 03:16, Brian Gregory wrote:
On 15/02/2020 04:27, Mayayana wrote: Â*Â* I use BMP or TIF for that. I could use PNG but it's relatively bloated and it's also complex. Try saving a big image as TIF and then PNG. PNG is a lot of work to pack and unpack. It's slow. And as I wrote to Java Jive, I did a test yesterday and found that PNGs are much bigger than TIFs. You might use BMP? Yet you go on to moan about large size of PNG? I don't notice any difference in speed between PNG and TIFF. You running an 8086? Also I just tested with a photo and the PNG was actually a little smaller than the TIFF suggesting that whenever you use to export to PNG isn't correctly optimising the compression. Actually I think it depends which of the many compression methods the ludicrously complex TIFF format supports happens to be the default in whatever software you're using because I tried again with a different image editor and the TIFFs were then about 30% smaller than the PNGs. -- Brian Gregory (in England). |
#72
|
|||
|
|||
Image formats
"Brian Gregory" wrote
| You might use BMP? Yet you go on to moan about large size of PNG? | I don't notice any difference in speed between PNG and TIFF. | You running an 8086? | Also I just tested with a photo and the PNG was actually a little | smaller than the TIFF suggesting that whenever you use to export to PNG | isn't correctly optimising the compression. | Suit yourself. For me it's just a practical issue, not an emotional one. You're free to use PNG. I'm fond of BMPs because I can have them display as icons and they show in my Explorer Bar. I don't happen to have that for TIFs. So I use TIFs when I care about size, like when I have an image that might be very big as a BMP and I want to store is without loss of quality. For smaller images BMPs are nice because I can see them in Explorer folders without using thumbnail view, which I dislike. |
#73
|
|||
|
|||
Image formats
"Brian Gregory" wrote
| happens to be the default in | whatever software you're using because I tried again with a different | image editor and the TIFFs were then about 30% smaller than the PNGs. | I think you'll find a big range. It depends on how well the image compresses. If it's a simpler image it will likely be much smaller as a TIF. But a complex photo image may be smaller as PNG. I have a 5 MB photo that I tried converting to both formats. PNG at 6 compression took about 8 seconds. At 9 it took about 30 seconds and oddly, wasn't any smaller. TIF was almost instant. But in that case the PNG was smaller. (No, not an 8086. AMD FX-8300, 8-core 3.6 GHz.) The conversions were all in IrfanView. |
#74
|
|||
|
|||
Image formats
Mayayana wrote:
"Brian Gregory" wrote | happens to be the default in | whatever software you're using because I tried again with a different | image editor and the TIFFs were then about 30% smaller than the PNGs. | I think you'll find a big range. It depends on how well the image compresses. If it's a simpler image it will likely be much smaller as a TIF. But a complex photo image may be smaller as PNG. I have a 5 MB photo that I tried converting to both formats. PNG at 6 compression took about 8 seconds. At 9 it took about 30 seconds and oddly, wasn't any smaller. TIF was almost instant. But in that case the PNG was smaller. (No, not an 8086. AMD FX-8300, 8-core 3.6 GHz.) The conversions were all in IrfanView. I tried this test too. I was shocked to discover that PNG 0 was 70MB, PNG 1 (slight compression) was 37MB, and PNG 9 (max compression) was 37MB. In other words, a picture from a camera, there was only one level of lossless compression available in a sense. It makes the compression level setting (almost) worthless. The JPG it was made from was maybe 6-7MB or so. JPG can have quite high compression, and the ratio of the sizes isn't that high of a compression by JPG standards. The secret weapon for JPG is the turbojpeg library. It uses SSE, AVX, and/or multiple cores. And while there is IDCT acceleration (inverse discrete cosine transform) available from video cards, I don't know whether that fits into viewing or not. When I tried JPG in Irfanview for example, it appeared "instantly" on the screen. Whereas for PNG, I doubt those sorts of acceleration are on offer. One thing that was weird, was when I saved out a PNG with "zero" compression, the output step was still slow. And someone did think of parallelizing PNG compression. He views it as the same problem as PIGZ (which is a parallelized GZIP compressor, I think runs on two cores at least). Maybe the idea is to break a PNG file down into multiple IDAT blocks, and do a compression for each one on a different core. The blog entry is from August 30, 2018. https://brionv.com/log/2018/08/30/pa...-a-png-anyway/ It's amazing how slowly parallization passes into software lore. Even PIGZ (a "prototype of parallelization") did not get picked up in any substantial way. (I don't think Igor included that in 7ZIP for example, only 7Z got accelerated.) If you want GZIP compression, it's still largely a "single-core world". Paul |
#75
|
|||
|
|||
Image formats
"Paul" wrote
| | I tried this test too. | | I was shocked to discover that PNG 0 was 70MB, PNG 1 (slight compression) | was 37MB, and PNG 9 (max compression) was 37MB. In other words, a picture | from a camera, there was only one level of lossless compression available | in a sense. It makes the compression level setting (almost) worthless. | | The JPG it was made from was maybe 6-7MB or so. JPG can have quite high | compression, and the ratio of the sizes isn't that high of a compression | by JPG standards. | I think that's the key. JPG. I've noticed that a JPG put into a ZIP file typically gets 1-3% compression. That's probably the header. But a text file typically gets 90% compression. I also tried an image of a world heat map from online -- a very simple chart with only a few colors. In that case the PNG was smaller than the TIF. |
Thread Tools | |
Display Modes | |
|
|