Bug 197288

Summary:	dcraw produced images are a mess - at least on x86_64
Product:	[Fedora] Fedora	Reporter:	Michal Jaegermann <michal>
Component:	dcraw	Assignee:	Nils Philippsen <nphilipp>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-02-08 11:54:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michal Jaegermann 2006-06-29 21:20:04 UTC

Description of problem:

I am trying to read a raw image from a Canon EOS 30D camera and I am
doing that on FC5-x86_64 installation.  I see something like that:

$ dcraw -h -v _mg_0060.CR2
Loading Canon EOS 30D image from _mg_0060.CR2...
Scaling with black=203, pre_mul[] = 37.696503 16.000000 17.651888 16.000000
Converting to sRGB colorspace...
Flipping image 0:V:T...
Writing data to _mg_0060.ppm...

A resulting image has four "tiles", with some "gaps" between them.
They obviously come from the original but colours are clearly
out-to-lunch and results are not even close to what they should be.

I am seeing the same four "tiles" when I try 16-bit images (option '-4')
and colours are messed up even more.  Yes, I do have a program which
can handle and display images of that depth.

The above is in a marked contrast to the situation when I am using
'dcraw' compiled from the current sources.  This is
   $Revision: 1.332 $
   $Date: 2006/06/23 07:36:10 $
as opposed to
   $Revision: 1.308 $
   $Date: 2005/12/11 01:07:33 $
to be found in FC5.  When applied to the same raw image I see
(note different scaling and pre_mull factors and these factors
are not the previous ones just divided by 16).

$ ./dcraw -h -v _mg_0060.CR2
Loading Canon EOS 30D image from _mg_0060.CR2...
Scaling with black=128, pre_mul[] = 2.357733 1.000000 1.351584 1.000000
Converting to sRGB colorspace...
Flipping image 0:V:T...
Writing data to _mg_0060.ppm ...

and results display in other programs as expected.

In 16-bit case results still display too dark, with all colour information
apparently "scrunched" to one side, but I cannot tell if ./dcraw
or a program used to display that (cinepaint) is at fault.  At least
I am getting a picture instead of a bunch of "tiles".

I am afraid that 'dcraw.c' changed too much between versions for me
to be able to tell right away which changes were essential.

Version-Release number of selected component (if applicable):
dcraw-0.0.20051211-1.2

How reproducible:
on all raw files I tried

Comment 1 Nils Philippsen 2007-02-01 17:22:18 UTC

Rawhide has dcraw-8.53-1.fc7 building right now. Can you please check whether
this fixes your tiling problem? It's pure C, so it might work on FC6, shout if
it doesn't or you want something built for FC5.

As for 16bit images appearing dark, see the FAQ on the dcraw homepage:

"""
Why is 16-bit output dark / unreadable?
    If you want pretty pictures straight out of dcraw, stay with 8-bit output.
16-bit linear output is the best raw material for professional image editors
such as Photoshop and CinePaint, but it's no good for most image viewers.
"""

Comment 2 Michal Jaegermann 2007-02-02 02:24:31 UTC

> Can you please check whether this fixes your tiling problem?

At least for Canon EOS 30D raw images (all I have an access to)
it does.  Not that surprising as earlier dcraw versions was able
to do that as well.

> As for 16bit images appearing dark

16-bit images loaded in CinePaint look quite decent even after
"automatic Levels" was applied - does not matter if they were
produced in ppm or tiff format - and after that results can be
improved.  Not before that operation, though.  Maybe with other
types of raw images this is better?

If would be nice to have a corresponding ufraw with plugins though. :-)
http://ufraw.sourceforge.net/

Comment 3 Nils Philippsen 2007-02-08 11:54:27 UTC

FWIW I've built ufraw-0.10 for Rawhide yesterday. Anyway, I'll close this bug then.