mkidd

The file from ray-logic (http://www.mediafire.com/?zymyn2lm1ui) with the .png extension is not a PNG file but rather what appears to be a PDN file which mistakenly has the .png extension. The first four characters of the file are 'PDN3'. When opened in Paint.NET 3.5.2 it also generates the unhelpful "There was an error opening the file." message though the reason is much more straightforward than the case that started this thread.

I think I figured this one out. If I remove the pHYs chunk from PNG file (in my case using a hex editor), Paint.NET loads the image fine. That means removing this sequence of bytes starting at file offset 0x6a. 00 00 00 09 70 48 59 73 00 00 00 00 00 00 00 00 01 ea 65 16 a4 The first long int (00 00 00 09) specifies the chunk data size. The next four bytes (80 48 59 73 = pHYs) specify the chunk type and the final long int is a checksum. According to the PNG 2.1 specification, the chunk data itself specifies the X and Y pixel dimensions, (long ints) either as an aspect ratio (if last byte is 0) or pixels / meter (if last byte is 1). The data in the problematic file translates to 0 pixels / meter in each dimension. The standard does not address how 0 should be treated, which presumably results in to library dependent behavior. My understanding is that Paint.NET uses .NET libraries for loading images and they may be taking a strict view on the matter and throwing an exception, literally or figuratively. Most PNG files simply do not include the pHYs chunk in which case the standard directs decoders to assume a 1:1 aspect ratio, i.e. square pixels. I think the software for the scientific camera we are using wrote a slightly invalid TIFF file, i.e. one with the pixel aspect ratio explicitly defined as 0:0. Photoshop probably saw this explicit definition and blindly mapped it to the pHYs chunk.

The image is now available at http://www.mediafire.com/file/4ckcvig7ulq/Beads.png SHA1 Hash: E31E33ABE9C5FBF37E005207646F2251C0E2F1AD

When I try to load a certain PNG image in Paint.NET 3.36, I get the message "There was an error opening the file." without any further details. The image opens fine in Windows Picture and Fax Viewer (WPFV), Microsoft Office 2003 Picture Manager, IrfanView (4.10), Photoshop 5.5, and Matlab. The image file is about 1.4 MB, which exceeds the 256 KB limit imposed by the forum software, but I would be happy send it by other means. The only obviously peculiar thing about the file is that it has the exact same data on each image plane, i.e. it is a grayscale inefficiently stored in an RGB format. This PNG was created from a 24-bit TIFF file using WPFV. Paint.NET could not load the TIFF file either, although all the other applications cited above could. Curiously though, if I convert the TIFF to BMP using WPFV, Paint.NET can read the BMP file. And more bizarrely, I can load the PNG into Photoshop and save it again a new PNG file using the default PNG save options (Interface: None / Filter: Adaptive) and then read the resulting smaller (1099 KB) file into Paint.NET successfully. Other Photoshop save options, e.g. None/None or Adam7/Adaptive also yield PNG files that Paint.NET can read.

Yes and no! It depends on what you mean by 50%. Photoshop 5.5 uses 7F7F7F which matches one definition of 50%. But given the 2.2 gamma of an sRGB display, in actual light output this corresponds to (127/255) ^ 2.2 = 21.6% of full intensity in photons.

The top-to-bottom grayscale gradient on the desktop area of Paint .NET (3.30 in my specific case) can cause serious toning misjudgments. I didn't fully appreciate this until a colleague pointed out how much it was throwing him off, i.e. printed results didn't seem to match on-screen results due to improper relative corrections applied to the top and bottom areas of images, say sky vs. ground. It seems that the plain uniform gray background in Photoshop is actually pretty important. I don't know whether this should be considered a discussion topic or a bug. From a design perspective it does seem to be a bug. It would certainly be easy enough to change or provide an option to allow it to be changed. Maybe there is a already a way to change it that I am foolishly overlooking?

It is not as bad as writing your own codec. You can use the free Independent JPEG Group codec. It gives you access to the low level JPEG information. The latest version (6b), jpegsrc.v6b.tar.gz, can be downloaded at http://www.ijg.org/files/. Rather inconveniently, you need some sort of tool to unpack the Unix style gzipped TAR file, but 7zip (http://www.7-zip.org/) will do that for you without the hassle of installing all the Cygwin tools just to get gzip.exe and tar.exe.

I have read the discussion in the thread viewtopic.php?f=12&t=20431&p=100540&hilit=jpeg#p100540 and understand Rick Brewster's desire not to present an overly complicated quality options for saving JPEG images. However, I would like to suggest an option (a simple check box) to save an image using the same quality settings that were used in the JPEG file originally loaded into Paint.NET (assuming a JPEG was originally loaded). This would allow small edits to be made to a JPEG with minimal degradation without increasing the file size. First, a little background. JPEG quality is actually determined by the Discrete Quantization Tables (DQTs) and optional subsampling factors for each color plane, where the RGB image in transformed into one intensity (Y) and two chrominance (Cr, Cb) planes before the operations involving the DQTs and subsampling are applied. Since each DQT is an 8 x 8 matrix, it is a rare person who can rattle off the exact DQTs that they want. Therefore, the Independent JPEG Group (IJG) came up with a simplified linear quality scale of 0-100 where each integer is mapped to a particular set of DQT tables and subsampling factors. This scheme is implemented by a number of free JPEG read/write utilities and is therefore very common. However, it does not necessarily give the best visual results; it is notable that no digicams nor any Photoshop JPEG image quality settings use this scheme. Thus, there is no JPEG quality setting on the 0-100 simplified scale that accurately reflects what was used to encode most images originally. The upshot is that when a JPEG image originally created by a digicam, Photoshop, or various other programs is modified in Paint.NET, its quality will be degraded if it is saved at quality setting that results in a similar file size. One way around this problem, is to record the DQT and subsampling parameters from the JPEG when it is loaded and use the same exact DQT and subsampling values when resaving the image. A slight bit of numerical roundoff error is inevitable, but the damage is nearly minimized without excessive programming or undue complication of the user interface. Alternatively, there is the optimal solution, but it requires quite a bit more programming. Understand that JPEG images are encoded in 8 x 8 pixel blocks (or 16 x 8, 8 x 16, 16 x 16 etc if subsampling is used). If a JPEG is resaved using the same DQT and subsampling values, the original discrete cosine transform (DCT) values can be imported from the original JPEG for the blocks which have not been altered, i.e. in which no pixel has been altered. Then the damage is both minimized and limited to the regions that are changed. Implementing this requires a detailed unpacking of the original JPEG, comparison of the original JPEG with the image to be saved, and more data manipulation at the DCT level. Though the result would be very nice, it is not simple (I have only seen one commercial Photoshop extension that claims to do it). BTW, if you are truly curious about JPEG innards, you can grab a copy of JPEGsnoop at http://www.impulseadventure.com/photo/j ... ver=0.8.1a).

URLs invoked in Paint.NET should open in the default browser to comply with expected Windows application behavior. In Paint .NET 3.10 and earlier, menu items such as Help --> Help Topics and Help --> Paint.NET Website always open in IE even if the default browser is different, e.g. Firefox.