Issues with some ZIP-compressed output DNGs (possibly related to 'strip' TIFF-output issue solved in 13.7)

[Luke Davis]

Hello,

I recently purchased PTGui Pro 13.7, and I think I found a DNG-output ZIP compression bug that may be related to the TIFF output compression issue mentioned in the version history. I've been going through a large library of RAW photos and stitching them in PTGui, after first converting them to DNG with Adobe RAW Converter. In the "Create Panorama" tab, I select 16-bit DNG output (no alpha) with ZIP compression enabled. Out of a couple hundred of these panoramas, most are great, and I can view/edit them just fine. But about 5% are not readable in the RAW editing software I use (Darktable). When I try to view them in the Darktable GUI, I get the error "Image could not be loaded: Unsupported format". When I run a command-line script provided by Darktable, and the script encounters one of these problem files, Darktable gives me the following more helpful error message:

image 2559/2559 (100.00%) (id:13841, file=IMGP9283 Panorama.dng)

   866.6972 [rawspeed] IMGP9283 Panorama.dng corrupt: void rawspeed::AbstractDngDecompressor::decompress() const, line 251: Too many errors encountered. Giving up. First Error:

rawspeed::LJpegDecompressor::LJpegDecompressor(RawImage, iRectangle2D, Frame, std::vector<PerComponentRecipe>, int, Array1DRef<const uint8_t>), line 129: Tile size is smaller than a single frame MCU

What stood out was the end of the message: "Tile size is smaller than a single frame MCU". This reminded me of the version 13.7 changelog. So, I was wondering if the same 'strip' format (whatever that means...) is still being used for ZIP-compressed output DNG panoramas. And if so, was wondering if that could be causing the issue. I've attached a sample problem file in case it helps.  

Side note, I find that I get the best results when I convert my RAW files (PEFs taken with a Pentax K-5) to DNGs before stitching. Otherwise, I find the white balance seems to get "baked into" the output DNG, and as a result, I have to treat these files differently from my other images by skipping additional white balance scaling of the R G B channels. This also means further white balance corrections after stitching are not possible. I also notice some minor-to-medium color differences between my original PEF files and DNGs directly stitched from the PEFs. But when I convert the PEFs to DNGs first, the colors in the output DNG are almost identical to the originals, and white balance scaling works just like in any "true" RAW file. Not sure if these issues are already known, but wanted to mention them.

Luke

[PTGui Support]

Hi Luke,

Could you send me one of the problematic files so I can take a look? And
have you tried opening the image in Adobe Raw?

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> ptgui/8914a8b9-a4c0-498a-a805-8aa30735fbddn%40googlegroups.com <https://
> groups.google.com/d/msgid/ptgui/8914a8b9-a4c0-498a-
> a805-8aa30735fbddn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Luke Davis]

Hi Joost,

Sorry couldn't attach it in the original message. Here is a sample panorama that won't open in Darktable. I decreased the output size to ~10% so I could share it -- Was wondering if that would also fix the issue, but the issue appears to be independent of the output size. I don't use Adobe Camera RAW (I only use their free DNG converter) but I can the image in FastRawViewer just fine at any output size.

Thanks,

Luke

[Luke Davis]

Hi Joost,

To give some more info on the Darktable error message: When I try to scroll over the file in the GUI, it says "File 'IMGP6904 Panorama.dng' uses an unsupported feature.". So it doesn't seem to be corrupt or anything, and Darktable recognizes the image data is there, it just can't uncompress it.

Luke